System and method for remote device recognition at public hotspots

ABSTRACT

Described are various embodiments of a system and method in which device-identifying data can be used to uniquely recognize and optionally track and report on device activity at one or more hotspot locations by way of the creation and management of a device profile uniquely associated with such devices and stored in a network accessible knowledge base.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation-in-part of U.S. patent applicationSer. No. 12/451,909, filed on Jan. 7, 2010, which is a U.S. NationalPhase of International Application No. PCT/CA2008/001060, filed on Jun.6, 2008, which claims priority to a U.S. Provisional Patent ApplicationNo. 60/942,409, filed on Jun. 6, 2007. The disclosures of these priorapplications are incorporated by reference in their entirety and shouldbe considered a part of this specification.

FIELD OF THE DISCLOSURE

The present disclosure relates to wireless networks, and in particular,to a system and method for remote device recognition.

BACKGROUND

Wireless devices and systems are currently available for enabling a userof a remote device access to a communication network (e.g. the Internet)via a wireless access point (WAP) and gateway communicatively linked tothis communication network, for example, operated at a given location orin a given area commonly known as a hotspot.

There remains a need for a new system and method for remote devicerecognition that overcomes some of the drawbacks of known techniques, orat least, provides the public with a useful alternative.

This background information is provided to reveal information believedby the applicant to be of possible relevance. No admission isnecessarily intended, nor should be construed, that any of the precedinginformation constitutes prior art.

SUMMARY

Some aspects of this disclosure provide a system and method for remotedevice recognition. In accordance with one embodiment of the invention,there is provided a method for recognizing a wireless device acrossmultiple hotspot locations, the method comprising: detecting at one ofthe multiple hotspot locations a wireless transmission sent by thewireless device; extracting a unique device identifier of the detecteddevice from said wireless transmission, said unique device identifierautomatically embedded within said wireless transmission by the detecteddevice without user input; cross-referencing said extracted deviceidentifier with a network accessible database of stored device profiles,each of said device profiles having a respective stored deviceidentifier associated therewith; and recognizing the detected deviceupon matching said extracted device identifier with one said storeddevice identifier; otherwise automatically creating a new device profilein said database as a function of said extracted device identifier suchthat the device is recognized upon subsequent detection at any of saidmultiple hotspot locations.

In accordance with another embodiment, there is provided a system fortracking wireless devices across multiple hotspot locations, the systemcomprising: a network accessible database having stored therein aplurality of device profiles each identifying a respective wirelessdevice by a stored unique device identifier, each said stored uniquedevice identifier indicative of an inherent characteristic of saidrespective device; and a network access module at each of said locationsand configured to detect at a given location a wireless transmissionsent from a given device and having embedded therein a transmittedunique device identifier inherent to said given device; said networkaccess module interfacing with said network accessible database tocross-reference said transmitted unique device identifier with saidplurality of device profiles to identify a matching profile and therebyrecognize said given device, and otherwise automatically create a newdevice profile based on said transmitted unique device identifier so torecognize said given device upon subsequent detection at any of saidmultiple hotspot locations.

In accordance with another embodiment, there is provided method forautomatically characterizing a device visit at a Wi-Fi hotspot location,comprising: detecting a first wireless transmission sent by a wirelessdevice; extracting a unique device identifier of the detected devicefrom said wireless transmission, said unique device identifierautomatically embedded within said wireless transmission by the detecteddevice without user input; creating a device visit profile andassociating said extracted unique device identifier therewith; recordinga timestamp of said first wireless transmission in said device visitprofile; automatically identifying one or more subsequent wirelesstransmissions sent by said wireless device while at the Wi-Fi hotspotlocation by way of identifying data associated with each of saidsubsequent transmissions directly or indirectly associated with saidunique identifier; recording a timestamp of each of said subsequenttransmissions in said device visit profile; and characterizing saiddevice visit profile at least as a function of a duration value definedby said recorded timestamp of said first transmission and a recordedtimestamp of a last of said subsequent transmissions.

In accordance with another embodiment, there is provided a method forrecognizing a wireless device across multiple Wi-Fi locations, themethod comprising: detecting at one of the multiple Wi-Fi locations awireless transmission sent by the wireless device; extracting a uniquedevice identifier of the detected device from said wirelesstransmission, said unique device identifier automatically embeddedwithin said wireless transmission by the detected device without userinput; cross-referencing said extracted device identifier with a networkaccessible database of stored device profiles, each of said deviceprofiles having a respective stored device identifier associatedtherewith; recognizing the detected device upon matching said extracteddevice identifier with one said stored device identifier; andassociating with said device profile of said recognized device said oneof the multiple Wi-Fi locations; and centrally compiling from saidstored device profiles, visit data for each of said multiple Wi-Filocations.

Other aims, objects, advantages and features will become more apparentupon reading of the following non-restrictive description of specificembodiments thereof, given by way of example only with reference to theaccompanying drawings.

BRIEF DESCRIPTION OF THE FIGURES

Several embodiments of the present disclosure will be provided, by wayof examples only, with reference to the appended drawings, wherein:

FIG. 1 is a high level diagrammatic representation of a remote serviceaccess system, in accordance with embodiments of the invention;

FIG. 2A is a high level diagrammatic representation of an exemplaryremote device, in accordance with embodiments of the invention;

FIG. 2B is a high level diagrammatic representation of a service accessmodule, in accordance with embodiments of the invention;

FIG. 2C is a high level diagrammatic representation of a network accessmodule, in accordance with embodiments of the invention;

FIG. 3 is a flow diagram depicting a method of registering a user and aremote device for access to the system of FIG. 1, in accordance withembodiments of the invention;

FIG. 4 is a flow diagram depicting a process of identifying,authenticating, and authorizing a user with a browser-based or browserchallenged mobile or remote device, in accordance with embodiments ofthe invention;

FIG. 5 is a sequence diagram depicting communications between componentsof the system of FIG. 1, for identifying, authenticating, andauthorizing a user with a browser-based or browser challenged mobile orremote device, in accordance with embodiments of the invention;

FIG. 6 is a flow diagram depicting a process of identifying,authenticating, and authorizing a user with a browserless mobile orremote device, in accordance with embodiments of the invention;

FIG. 7 is a sequence diagram depicting communications between componentsof the system of FIG. 1, for identifying, authenticating, andauthorizing a user with a browserless mobile or remote device, inaccordance with embodiments of the invention;

FIG. 8 is a flow diagram depicting a method of accessing wirelessservices using a browser-based remote device, in accordance withembodiments of the invention;

FIG. 9 is a flow diagram depicting a method of accessing wirelessservices using a browser-challenged remote device, in accordance withembodiments of the invention;

FIG. 10 is a flow diagram depicting a method of accessing wirelessservices using a browserless remote device, in accordance withembodiments of the invention;

FIG. 11 is an exemplary screen shot depicting a relational databasecontaining sample data of hotspot access networks, user profiles, anddevice profiles, in accordance with embodiments of the invention;

FIG. 12 is a flow diagram depicting an exemplary method for extractinginformation from a remote device, according to an embodiment of theinvention;

FIG. 13 is a diagram of an exemplary system hardware architecture fordevice detection and recognition, in accordance with one embodiment ofthe invention;

FIG. 14A is a high-level diagram depicting progressively increasingengagement levels between a wireless device and a hotspot, anddistinguishing passive and active visitors at this hotspot as a functionof their engagement level, in accordance with an embodiment of theinvention;

FIG. 14B to 14D are diagrammatic representations of respective visitprofiles, in accordance with an embodiment of the invention, in whichdifferent device detection and network interaction events are used tocharacterize each visit.

FIG. 15 is a diagram of an exemplary process flow for device detection,and recognition, visit data compilation and processing related thereto,and downstream applications associated therewith, in accordance with oneembodiment of the invention;

FIG. 16 is an exemplary screenshot of a system reports and analyticssite consolidating visit and device-related data accessed over time inrespect of a plurality of participating hotspots and/or hotspotoperators;

FIGS. 17A and 17B are exemplary graphical user interfaces providing areal-time dashboard of device and visit-related data in respect ofmultiple hotspots operated by a common hotspot operator, and in respectof a single hotspot, respectively, in accordance with one embodiment ofthe invention; and

FIG. 18 is a diagrammatic representation of illustrative downstreamapplications for a device detection and recognition system, inaccordance with one embodiment of the invention.

DETAILED DESCRIPTION

With reference to FIG. 1, and in accordance with one embodiment, apublic network access system will now be described. The system 10 isconfigured to provide one or more remote devices 102 access to one ormore services 114 via a network 104. In the embodiment depicted in FIG.1, the system generally comprises one or more network access modules106, adapted for communicating wirelessly with the one or more remotedevices 102, and one or more service access modules as in module 112,communicatively linked to the network access module(s) 106 andconfigured to provide to the remote device(s) 102 access to theservice(s) 114 via the network access module(s) 106 and network 104.

In general, the system 10 may be used to identify different remotedevices 102 via the network access module 112, and in some embodiments,authenticate and authorize access thereto to network and/or Web-basedservices accessible via the service access module 106. In someembodiments, the system 10 allows browser-based, browser-challenged,and/or browserless remote devices to access these services, or aselection thereof, when such remote devices are operated at a publicaccess hotspot supported by the system 10.

For example, the network access module 106 may be configured forreceiving identifying data from a remote device 102, and communicatingthis identifying data to the service access module 112 forauthentication and authorization. Once the identifying data isauthenticated, the service access module 112 will authorize that theremote device 102 access the network 104 and services 114 providedtherethrough. In some embodiments of the invention, the system 10 may beconfigured to provide full access to each remote device 102, or againeach remote device type, or provide restricted access to selectedservices 114 based on user information, remote device owner or typeinformation, service provider information, related purchase information,service promotions offered by service provider partnerships oragreements, and/or a combination of the above and other such informationavailable through the system 10. Identifying data may, for example,comprise remote device type data automatically embedded within remotedevice transmissions and extracted by the system 10, remote device typedata extracted from user preferences available from the remote device,user data input thereby using a user interface (e.g. username andpassword, etc.), or a combination thereof, to name a few.

In some embodiments, user information or data resides or is entered orstored on the remote device and is compared to a user profile stored ina knowledge base operatively coupled to the service access module. Insome embodiments, as an aid to authentication, at least a portion ofuser information is not stored on the remote device but is provided bythe user when access is required. Similarly, in some embodiments, remotedevice information or data resides or is stored on the remote device andis compared to a remote device profile stored in a knowledge baseoperatively coupled to the service access module. Remote deviceinformation can be indicative of inherent characteristics of the remotedevice, such as a MAC address, or can be other information stored on theremote device for identification thereof.

Authorization or restriction of access to selected services can beenabled by establishing one or more service profiles. A service profilecan associate information about users, remote devices, hotspotproviders, hotspot locations, or service providers, or a combinationthereof with a collection of allowed or restricted services, resourcesor applications to be provided. For example, the service profile caninclude information about services which a user has paid for andsubscribed to, services usable by a remote device, and/or servicesoffered by a hotspot provider, hotspot location, or service provider. Asanother example, the service profile can additionally includeinformation about service offerings provided to specified combinationsof user, remote device, hotspot provider, hotspot location, and serviceprovider. Service profiles can be stored in a knowledge base, andaccessed to determine what access should be given upon initiation of aconnection of a remote device at a hotspot.

In some embodiments, the user profile and/or remote device profile areassociated with the service profile in the knowledge base. Duringauthentication and authorization, user and/or remote device informationprovided by the remote device is compared with the user profile and/orremote device profile in the knowledge base for validation, and accessto services as described by the service profile are granted uponvalidation.

In one embodiment, authorization constraints can be associated with aservice profile and used to directly or indirectly limit or disablespecified applications, or to limit or disable network accessfunctionality related to said specified applications. Authorizationwhitelists can also be used, as an alternative to or in conjunction withauthorization constraints, to positively define access to services or toprovide minimum service level guarantees.

The system 10 generally provides one or more remote devices 102 accessto one or more services 114 via network 104. For example, the system 10could be used to provide access to digital home services, such as accessto digital TV or other forms of home content to access applications suchas, but not limited to, Slingbox, Orb, Location Free TV (LFTV), and/orhome security features provided by various online home security serviceproviders. A user could thus connect to a home access system (e.g. ahome media server, networked computer, etc.) to access images, music,videos, files, and the like that are stored on remote devices located inthe user's home, business, office, etc. The system 10 could also be usedto access remote media services, for example from another remote device102 supported by the system 10, from a Web-enabled media serviceprovider (e.g. music and/or video download, sharing, etc.), or fromother such networked services.

Other examples of services 114 could include access to instant messagingservices, such as but not limited to, AOL™ Instant Messenger, Microsoft™MSN Messenger™, Yahoo!™ Messenger, ICQ, or Google™ Talk, access tovarious public, private and/or enterprise email services, such as butnot limited to, Hotmail, Gmail, Yahoo!™ Mail, AOL™ Mail, Microsoft™Outlook™, as well as access to enterprise business applications such as,but not limited to, collaborative platforms using, for example,Microsoft™ Unified Communications (e.g. Outlook™, Messenger,Sharepoint™, Microsoft™ Communications VOIP services, etc.), and thelike. Access could also be provided to social networking applicationssuch as Facebook™ MySpace™ and YouTube™. Access could also be providedto cloud storage systems such as SkyDrive™ and Google Docs™, or othervirtualized computing resources. Furthermore, access to various gamingservices, such as OGSi, GamePal™ PlayStation™ Network, Xbox™ Live™,Nintendo™ Wi-Fi, and the like, could also be implemented via system 10.

In some embodiments, services can be characterized at least in part asallowing access to groups of applications, and/or as allowing access tospecified network resources at specified levels. For example, networkresources can include sets of one or more TCP or UDP ports, datatransmission or reception capabilities at a specified bandwidth,bandwidth variation, delay, delay variation, communication priority,support for specified sources or destinations, application or removal ofpacket size restrictions, and the like, as applied to either upstreamtraffic, downstream traffic, or a combination thereof. Specified networkprotocols, for example protocols supporting streaming video or audio,can also be considered network resources.

In some embodiments, services characterized by allowing access to groupsof applications and/or specified network resources or levels thereof canbe further characterized by other aspects, such as allowing access tospecified applications, to specified remote devices or at specifiedlocations, times, or the like.

In some embodiments, network resources such as described above can beselectively allowed or blocked in order to enable or disable access toone or more selected applications. For example, if a customer subscribesto a streaming audio application, access to appropriate TCP ports,streaming audio servers, and network traffic characteristicsrepresentative of streaming audio can be allowed such as support thestreaming audio application. However, communication with streaming videoservers may optionally be blocked unless the customer pays an additionalfee. Applications and/or groups of applications can be profiled toassociate therewith the network resources or characteristics requiredfor access thereto. Service providing access to selected applicationscan then be enabled by allowing access to the network resources orcharacteristics associated therewith, for example by looking up theappropriate associations in a knowledge base.

It will be appreciated by the person skilled in the art that access toany one, or combination of the above, and other such services may beprovided to a user of the system 10, without departing form the generalscope and nature of the present disclosure. For example, a user couldgain access to the Internet, or similar network structures, on an openaccess basis, such that this user could browse the Internet, downloadfrom the Internet, play online games, etc., in one example, restrictedonly by possible functional, processing and/or communicationcapabilities and limitations of the user's remote device 102.Alternatively, access could be limited to services selected orpre-selected for a given user or user remote device, identified andauthenticated by the service access module 112 and authorized to accessthese limited services via the network access module 106.

As introduced above, in accordance with some embodiments of theinvention, the system 10 may be configured to manage public and/orprivate network access for a plurality of remote devices 102, optionallyof a plurality of remote device types, configurations and/orfunctionality, and that, within a variety of venues if necessary. Inthis embodiment, identification, authentication and authorization can beimplemented for a variety of remote devices and/or users, andoptionally, for different services and service access packages and/orrestrictions. Such packages could, in various embodiments, be defined bythe type of remote device used to access the system 10, e.g. based onremote device capabilities, functionality and/or limitations; thespecific user or remote device accessing the system 10, e.g. based on auser and/or remote device profile listing selected and/or pre-selectedservices; or a combination thereof, for example.

For instance, in one embodiment, access is provided in accordance with aselected or identified service access package wherein access is providedto one or more Value Based Applications (VBAs) selected or offered to agiven user and/or remote device. For example, VBAs can be offered eitherat no cost or as part of a paid service. Such VBAs may include a numberof remotely operable applications or service levels for which an enduser may wish to gain access via the present system. For example, a VBAcould comprise a specific application to which access is provided via amobile network, managed by remote device and/or network specificfunctionality, and priced according to the value delivered by thespecific application to a specific market segment. As another example, aVBA could comprise enabling a combination of capabilities and/or servicequality levels that are desired for effectively using a specificapplication or class of applications, priced according to the valuedelivered thereby. Pricing can include monetary payment, but can also beaffected by other factors such as purchases of related products,services or service contracts, association with a selected serviceprovider, or the pre-existence of other related products, services orservice contracts.

Enabling VBAs may thus provide access and cost flexibility to the enduser through specifically defined service profiles. These serviceprofiles can be packaged into a monetized service based on a specificfunctionality, for example, gaming, home connect, etc., and tied to theremote devices that support such functionality. Furthermore, anembodiment can be configured to enable the identification of a remotedevice 102 as a browser-based, browser challenged, or browserless remotedevice, and optionally configured to combine such remote deviceidentification with user identification. Embodiments can allow foraccess to the network 104 and services 114 using a service-basedaccounting, which permits users with browserless remote devices toaccess these networks 104, and can also facilitate service-orientednetwork access at hotspots and other such locations.

In some embodiments, a user can select and pre-pay for a service profilebased on price and desired functionality. Options to upgrade a serviceprofile can be provided, triggered by a user's attempt to access aservice other than described in their service profile, or to access aservice in a manner other than described in their service profile (forexample but not limited to: beyond a predetermined time limitation,outside of authorized hotspots, outside of a predetermined geographicarea, using an unauthorized remote device or remote device type,accessing an unauthorized application, simultaneously using more remotedevices than is authorized, or using resources beyond a predeterminedbandwidth cap or bit cap). It will be understood that a variety ofpre-paid or pay-as-you-go service plans can be implemented in someembodiments.

As examples of enabling restricted access to selected VBAs, a user maybe willing to pay a fraction of the traditional hotspot access price fora specific function or application, for example, offering, at adiscounted price, to only connect a given user to their home computer,watch TV from their home digital cable box, access a social applicationsuch as Facebook™, or keep a son or daughter entertained at the airportduring a 3-hour layover with a hand-held gaming remote device connectedto other players on the Internet. In an embodiment where suchauthorization packages are selected, the system 10 can be configured tomanage user accounts and apply customized authorization rules, such aswhitelists or constraints (e.g. firewall rules via gateway 110 of thenetwork access module 106 of FIG. 2C) such that a user may select onlyservices 114 they wish to pay for, or free services provided at theirlocation, which for example could be in conjunction with the purchase ofanother product at the location or a service partnership or agreement,and be restricted thereto. An upsell feature may also be implementedthrough the system 10 such that a user may choose to upgrade theirservice profile to gain access to further services 114.

As another example, quality of service, packet priority, bandwidth,traffic shaping, and the like, can also be affected by a serviceprofile. The service profile can be influenced by user and remote deviceprofile information, or service provider information. For example, auser may be willing to pay a premium for improved levels of servicethrough adjustment of the service profile, selected remote devices orremote devices associated with selected service providers can beautomatically given improved levels of service through adjustment of theservice profile, or a combination of such factors can influenceadjustment of the service profile. In some embodiments, service levelsas specified by a service profile can also be dependent on otherfactors, such as remote device, remote device type, location,application, and/or the like.

As another example, a service profile influencing access topredetermined functions or applications can be determined according tomarketing and sales strategies. For example, access can be linked to apurchase at a hotspot providing network access services. Such anoffering could be free access to one or more applications when a coffeeis purchased using a stored-value card. As another example, a frequentuser at a hotspot could be given a preferred pricing rate, extended timeallowances or enhanced access to applications based on previous historyof purchases at the hotspot or selected affiliates. Influencing serviceprofiles, for example by a service provider or hotspot location, can beperformed on a permanent or trial basis, for example for market ortechnical research purposes.

It will be appreciated that various service packages providing access toone or more VBAs may be contemplated in the present context withoutdeparting from the general scope and nature of the present disclosure,as can various examples, types and configurations of VBAs be combined orprovided exclusively in the context of a predefined or custom servicepackage. Furthermore, as will be described in greater detail below,various upsell mechanisms and opportunities may be provided within thepresent context to provide a user access to additional services, eitheras a supplement to an existing subscription package, a one-time trial orlimited subscription, or the like, for example. Service profiles,service provider partnerships, and the like can be combined to offeraccess to services such as communication resources, internet, email orsocial applications, based on one or more factors such as location, timeof day, remote device type, remote device service provider, hotspotservice provider, and the like.

With reference to FIG. 1, the system 10 may be implemented over variousdifferent types and combinations of networks 104 providing for thecommunicative interfacing of a given remote device 102, network accessmodule 106 and service access module 112. For example, network 104 maycomprise a combination of networks conducive to provide a user access toa diversity of services 114. For example, network access may be providedto Sling Media™, which allows a user to connect to their home Slingbox™device from a remote location; Sony™ Location Free TV, which allows auser to connect to their home Location-Free TV (LFTV) from a remotelocation; and/or Orb Networks™, which allows a user to connect to theirhome Orb™ server and retrieve content from their home server from aremote location. Access to other Internet, Web-enabled and/or networkservices may also be contemplated, including, but not limited to emailand messaging services, media access services, gaming services, businesscollaboration software, social applications, and the like.

In one embodiment, the system 10 comprises a single-cell hotspotwireless network, generally comprising a local area network (LAN) or thelike limited to a relatively small spatial area such as a room, a singlebuilding, a ship, or an aircraft, otherwise commonly referred to as asingle location network.

In another embodiment, the system 10 comprises a wide area network, suchas, but not limited to a muni-Wi-Fi network or the like, and isimplemented using one or more of a variety of technologies such as astrand-mounted network, a mesh network, and the like. A wide areanetwork could comprise, for example, a metropolitan area network (MAN)that connects two or more LANs together but typically does not extendbeyond the boundaries of the immediate town, city, or metropolitan area.Multiple routers, switches, and/or hubs can be connected to create a MANusable in the present context.

In another embodiment, the system 10 comprises a wide area network(WAN), such as, but not limited to a WiMAX Network or the like. A WANcould comprise, for example, a data communications network that covers arelatively broad geographic area using transmission facilities providedby common carriers, such as telephone companies, interne companies, andother such communication service providers.

It will be understood by the person skilled in the art that variousother types and combinations of networks, either currently implementedor developed in the future to facilitate communications over diversegeographical areas, may be considered herein without departing from thegeneral scope and nature of the present disclosure.

With reference to FIG. 1, and in accordance with some embodiments of theinvention, a remote device 102, such as a wireless remote device, is adevice having the ability to communicate with other devices withouthaving physical contact with them. A remote device can be an electronicdevice operable as a wireless interface between a user or anotherelectronic device and a network or wireless access point, such asprovided at a hotspot or within a wireless network coverage area. Aremote device may include, but is not limited to, laptops, PersonalDigital Assistants (PDA), Smart phones (e.g. Apple™ iPhone™, HTC 5261,RIM Blackberry™ BOLD, etc.), wireless gaming devices such as theNintendo DS™, the Sony PSP™, the Sony My1o™, Wi-Fi Cameras, portableentertainment devices (e.g. Apple™ iPod™, iPod™ Touch) and other suchdevices currently available on the market, in development, or upcomingand based on similar communication platforms and technologies. A remotedevice may incorporate several functionalities such as those listedabove. A remote device can be capable of communicating using one or moredifferent communication modes, such as a combination Wi-Fi and/orcellular device. The person skilled in the art will appreciate that thesystem 10, as disclosed herein, is readily adaptable to new and upcomingdevices, and as such, is considered to include such devices within thecontext of the present disclosure.

With reference to FIG. 2A, and in accordance with some embodiments ofthe invention, a remote device 102 is depicted. In this embodiment, theremote device 102 generally comprises a computer-readable medium ormedia 208 for storing statements and instructions for the operation ofthe remote device, and optionally for storing various forms of datauseful in the implementation of remote device functions and/oraccessible to the user of the remote device as needed; a communicationmeans such as a communication device and/or interface 202 forinterfacing with the network access module 106 and optionally, fordirect communication with other similarly configured remote devices; oneor more processors 206 for processing received and sent information andfor implementing statements and instructions stored on the one or morecomputer-readable media 208; and a user interface (UI) 204, such as agraphical user interface (GUI), keyboard, keypad, game pad, mouse,scroll ball, touch screens, motion sensing user interface, speechrecognition system, or the like for receiving input from the userdirected to the operation of the remote device 102. Other remote deviceelements and/or components, as would be readily apparent to the personskilled in the art, may also be considered herein without departing fromthe general scope and nature of the present disclosure. For instance,various hardware, firmware and/or software may be integrated oroperationally associated with a given remote device 102 to achievevarious functions and interface with the user and/or various servicesaccessed thereby over the network 104. Also, various peripheral devices,such as supplemental user interfaces, data input and/or output means(e.g. printers, scanners, removable storage media, etc.), and the likemay also be considered herein.

In one embodiment, the remote devices 102 may include browser-basedremote devices, wherein such remote devices comprise a browser-baseduser interface 204, such as a Web browser or the like. Examples ofbrowser-based remote devices may include, but are not limited tolaptops, PDAs, and the like.

In another embodiment, the remote devices 102 may includebrowser-challenged remote devices, wherein such remote devices comprisea browser-challenged user interface 204, such as for example, amicrobrowser or the like, and/or comprise a substandard keypad (i.e.non-QWERTY keypad). In one example, a microbrowser is defined as a Webbrowser specially designed for a hand-held remote device and embeddedwithin the software and/or firmware of this remote device. In thisexample, the microbrowser is generally optimized so as to displayInternet content most effectively for small screens on portable remotedevices and have small file sizes to accommodate the low memory capacityand low-bandwidth of such handheld remote devices. Examples ofbrowser-challenged remote devices may include, but are not limited to, aSony™ PSP™ a Smartphone (e.g. Apple™ iPhone™, HTC 5261, etc.), aBlackberry™, and the like. Content providers may, in some instances, beconfigured to provide pre-formatted content specifically for some or allbrowser challenged remote devices.

In another embodiment, the remote devices 102 may include browserlessremote devices, wherein such remote devices comprise a browserless userinterface 204, for instance comprising a display and the ability toaccept user inputs (e.g. keypad(s), scroll ball(s), etc.) but notencompassing the functionality common to browsers and microbrowsers.Examples of browserless remote devices may include, but are not limitedto, a Nintendo DS™, a Wi-Fi camera, and the like.

The person of ordinary skill in the art will appreciate that otherbrowser-based, browser-challenged and browserless remote devices may beconsidered herein without departing from the general scope and nature ofthe present disclosure. This person will further appreciate that,although the above examples have been described with reference to threedistinct categories, other categories may also be contemplated based oneach remote device's functionality, operability and user interfacecharacteristics. Furthermore, it will be understood that certain remotedevices may be best described as falling between any of the abovecategories, and that such remote devices are considered within thecontext of the disclosed system 10.

With reference to FIGS. 1 and 2C, and in accordance with someembodiments of the invention, the network access module 106 of thesystem 10 comprises a wireless access point (WAP) 108 and a gateway 110.In this embodiment, the WAP 108 comprises a device configured to connectdifferent wireless communication devices together to form a wirelessnetwork, and further connect to one or more wired or wireless networks(e.g.

network 104), namely via gateway 110, to relay data between remotedevice(s) 102 and downstream wired and/or wireless devices.

In one embodiment of the invention, the WAP 108 reacts substantiallyimmediately when a remote device 102 scans for an available network. TheWAP 108 reacts to the remote device scan by communicating to the remotedevice 102 that there is an available network connection through thenetwork access module 106.

The gateway 110 can be used to communicate between a remote network andanother network, which, in the present context, may provide access tothe service access module 112. In this embodiment, the gateway 110comprises a device configured to communicate between two or morenetworks which may, for example, use different network protocols (e.g.wireless network protocols, wired network protocols, etc.). Examples ofgateways 110 operable within the context of system 10 may include, butare not limited to, Colubris Controllers (e.g. MSC-3200), Cisco™ WLANControllers (e.g. Cisco™ 2000, 4100 WLAN Access Controller), andMikrotik™ RouterOS, to name a few.

In one embodiment of the invention in which a browser-based or browserchallenged remote device is being used to access a network, the gateway110 may intercept the request to access the network 104 and redirect therequest back to the remote device 102 through a web browser for the userto input user information. The information requested can be for example,but not limited to, a username and password. The user information can beassociated with a user profile for identification, authentication andauthorization. Specific remote device information may also be extractedby the Service Access Module 112 (described below) from datacommunicated through the gateway 110 for the purposes of identifyingand/or authenticating the remote device being used to access thenetwork. Such remote device information may include, but is not limitedto, the Media Access Control (MAC) address of the remote device 102,traffic type (e.g. communication port, data type, communicationprotocol, traffic headers, etc.), browser type (e.g. full browser,microbrowser, browser origin and/or configuration, etc.), and/or someother unique identifier (e.g. remote device configuration, serialnumber, signature related to a remote device clock or crystaloscillator, etc.). This and related remote device information can beassociated with a remote device profile for identification,authentication and authorization. The gateway 110 receives the userand/or remote device information through the access point 108 andcommunicates the identifying information to the service access module112 for authentication and authorization. Once authorized, networkaccess is implemented, either as wide open access, or as restrictedaccess based on a number of access authorization criteria, which maydepend on the remote device type, the remote device configuration, thespecific remote device, the specific user, and/or other criteria, orcombinations thereof.

In one embodiment, the remote device profile and the user profile can beconfigured to indicate that network access is to be implemented withoutfurther interaction from the user, such as entering a user name andpassword. Authorization substantially without user interaction, forexample based on user profile information and remote device profileinformation which is automatically transmitted by the remote device, isreferred to herein as Express Authentication. In one embodiment, ExpressAuthentication can further include expedited user interaction, forexample, by requiring only a “one-click” or “one-action” connectionconfirmation from the user or requiring only a password or otherconvenient user data, such as biometric data, to connect.

In some embodiments, information used for authentication can includeuser provided information, remote device or remote device typeinformation, and/or other information such as one or more of: usercredit card information, prepaid service card information or PIN, useror remote device subscription information, access information or accesshistory, prepaid or stored value card or smart card information for ahotspot or associated product or service provider, PIN distributed forpromotional purposes, location information, usage time, date or time ofday information, or other information as would be understood by a workerskilled in the art.

In some embodiments, authentication can be performed using informationreadily accessible. Additionally, if the information initially availablefor authentication is insufficient for making an authentication decisionwith a predetermined level of certainty, additional information can beobtained. For example, authentication can be initially based on deviceinformation transmitted during an initial connection request, with anoption to request a user name and/or password if said transmitted deviceinformation cannot be used to uniquely identify the remote device. Asanother example, information resulting from a transaction related to theremote device can be used to support authentication. For example, if auser pays for a service or associated product or service with a prepaidor stored value card such as a smart card at the hot spot, informationresulting from the transaction can be used to support authentication.This may require correlating said transaction with the remote device,for example by entering a PIN on the remote device that is printed onthe transaction receipt. As another example, contextual information suchas time of day or location information can be used to supportauthentication. For example, usage time and location patterns of aremote device can be tracked, and if a remote device requests anatypical service or requests service in an atypical location, time ofday information may be used to determine whether it is more likely thatthe user's information or remote device has been stolen or whether theuser or remote device is associated with an atypical purpose for thatuser (such as vacation or leisure time instead of work time).

In some embodiments, user and remote device profiles are managed, forexample by a security management module and/or access management module,to reduce or deal with potential fraud, remote device theft, passwordtheft, or other misuse, and to improve user experience and accesscontrol. For example, information or suspicious activity can be logged,tracked and reported to assist in managing fraud, theft or other misuse.Security management can include automated or semi-automated management,or management by one or more service providers on behalf of the serviceproviders themselves, other service providers, or users. Management caninclude applications or services enabling tracking and analysis ofremote device or user activity, management of services, servicecontracts, manual or automated payment options, and the like.

In some embodiments, security is managed by one or more of requiringusers to provide username and/or password information; restrictingaccess parameters such as session time limits, concurrent usage by thesame user, geographic location, and/or the like; and other methods suchas Express Authentication, Advanced Device Profiling, multi-factorauthentication, authentication using an SMS messaging system, and frauddetection, or other methods as would be understood by a worker skilledin the art.

In some embodiments of the invention in which a browserless remotedevice is used to access a network, the gateway 110 detects the remotedevice request for network access and forwards it to the service accessmodule 112 (described below) where remote device information may beextracted from remote device communications, as described above. Ingeneral, the gateway 110 receives the user and remote device informationthrough the access point 108 and communicates this information to theservice access module 112 for authentication and authorization. Onceauthorized, network access is implemented, either as wide open access,or as restricted access based on a number of access authorizationcriteria. Said network access can be implemented based on theapplication of authentication constraints. In addition, depending onremote device and/or user registration settings, an optional request foruser information and/or confirmation may be communicated to a distinctremote device of the registered user for confirmation. For example, aconfirmation message could be sent to a user's cellular phone, or othersuch device, via a Short Message Service (SMS), wherein the user maythen confirm via this distinct device that they are in fact attemptingto access the system via their browserless remote device. In thisscenario, this would allow a user to identify an event where access tothe system is being erroneously and/or fraudulently attempted usingtheir remote device and/or remote device identity. It is contemplatedthat other multi-factor or strong authentication systems can beimplemented in conjunction with some embodiments. For example RSA™SecurID™, Phonefactor™ or similar services can be implemented duringauthentication. For example, location of a customer's cellular phone maybe determined by cell tower association or GPS to determine thelikelihood that the customer is indeed at the location whereauthentication is being requested. In addition, if authentication fails,the system can be configured to give the appearance that authenticationhas succeeded for the purposes of tracking or apprehending potentiallyfraudulent use.

In one embodiment, the gateway 110 may be configured to forward remotedevice communications to the service access module 112 where identifyingdata may be extracted from remote device transmissions only, whereinsuch identifying data may comprise remote device type information,specific remote device information, remote device configurationinformation and the like. Using remote device identification data onlyto connect can be described as a form of Express Authentication. Usingremote device identification data only enables the system 10 toauthorize different remote devices access to wide open services or aselection thereof based only on remote device data, and not on inputteduser data. This feature may be particularly useful in an example whereina browserless remote device seeks access to the network but wherein suchbrowserless remote device does not include functionality of aconventional type-in user interface allowing for the input of a usernameand password, for example. This feature is also applicable tobrowser-enabled or browser-challenged remote devices, to provide moreuser-friendly and faster connection to network applications. In anotherembodiment, Express Authentication can also include automaticallytransmitted user information, either automatically requested of andprovided by the user during authentication or stored on the remotedevice, or a combination thereof. For example, user information caninclude information stored on a cookie, or input by the user viainterface with the remote device.

It will be appreciated by a person skilled in the art that the functionsimplemented by the network access module may be provided by acombination of a WAP 108 and gateway 110, or applied using other devicearchitectures, known or developed, to provide such functionality.Furthermore, though the above examples contemplate forwarding remotedevice communications to the service access module 112 for identifyingdata extraction, it will be appreciated that the network access modulemay also be configured and adapted to extract such information fromremote device communications and forward this information to the serviceaccess module, or to other modules of the system for manipulation,without departing from the general scope and nature of the presentdisclosure.

Service Access Module

With reference to FIGS. 1 and 2B, and in accordance with someembodiments of the invention, the system 10 comprises one or moreservice access module(s) 112 configured to communicate with the networkaccess module(s) 106 to operatively identify, authenticate and authorizeone or more remote devices 102 access to one or more services 114.

In the example illustrated in FIG. 2B, the service access module 112generally comprises a computer-readable medium or media 218 for storingstatements and instructions for the operation of the module 112, and forstoring various forms of data useful in the implementation of modulefunctions and management of the service access module 112; acommunication means such as a communication device and/or interface 212for interfacing with the network access module 106 through the network104 and optionally, for direct communication with providers of the oneor more services 114; one or more processors 216 for processing receivedand sent information and for implementing statements and instructionsstored on the one or more computer-readable media 218; and an optionalmanagement interface 214, such as a graphical user interface (GUI),keyboard, keypad, mouse, scroll ball or the like for receiving inputfrom a system manager directed to the management of the service accessmodule 112.

It will be appreciated that other service access module elements and/orcomponents, as would be readily apparent to the person skilled in theart, may also be considered herein without departing from the generalscope and nature of the present disclosure. For instance, varioushardware, firmware and/or software may be integrated or operationallyassociated with the service access module 112 to achieve variousfunctions and interface with the remote device(s) 102, the networkaccess module 106 and/or various services 114 accessed thereby over thenetwork 104. Also, various peripheral devices, such as supplemental userinterfaces, data input and/or output means (e.g. printers, scanners,removable storage media, etc.), and the like may also be consideredherein. It will be further appreciated that the service access module112 may be implemented centrally, in a distributed architecture, or in acombination thereof to achieve a desired functionality and level ofcomplexity.

In the embodiment depicted in FIG. 2B, the computer readable medium 218of the service access module 112 comprises an access management module220 and a knowledge base 210, wherein the latter can be defined as astructured collection of records or data that is stored on the computerreadable media 218. As will be described below, when a user attempts toregister for an account, the network access module 106 (e.g. the gateway110 of FIG. 2C) accesses information from the user and/or the user'sremote device 102 and sends it over network 104, where it can be storedby the service access module 112, for example in a knowledge base 210.Information retrieved and stored may include such information as, butnot limited to, user name, user password, account number, number ofremote devices, remote device types, MAC Addresses, browser information,remote device configuration, service packages and/or user, remote deviceand service profiles, and the like. The database may also containinformation regarding the hotspot access point (e.g. the specificnetwork access module 106 implemented), for example, but not limited to,the hotspot access configuration and location information.

In some embodiments of the invention, remote device information such asremote device types, MAC Addresses, browser information, remote deviceconfiguration, clock or crystal oscillator information, serial numbers,and the like, is used to create an Advanced Device Profile (ADP) forauthentication purposes. The ADP can be used to identify, track, manage,and report on remote devices by remote device type, remote device model,or specific instance of a remote device. In some embodiments, forregistered remote device, remote device type, or remote device class, acopy of the advanced remote device profile can be stored for access bythe service access module, for comparison with characteristics of remotedevices attempting to connect to services through the network accessmodule for identification, authentication and authorization purposes.User or remote device access can be configured based on the ADP to allowaccess to be tailored toward the remote device, or to package accessprivileges with ownership of selected remote devices or subscription toselected service providers, for example. The ADP can also be used toenable Express Authentication, wherein user and/or remote deviceauthentication can proceed with reduced or no input from the user.

In some embodiments, remote device information, for example as can beused to create or verify against an ADP, is captured during negotiationof a connection between the remote device and the network access module.For example, in one embodiment, a remote device may send a request toinitiate a wireless connection with the network access module through anapplication such as a web browser. Depending on the remote device orremote device type, the request can contain different information, or beconfigured in different ways as would be understood by a worker skilledin the art. For example, a connection request can include specificallyconfigured fields in HTTP headers, configurations of portions of a querystring in a URL, MAC address, or other configurable aspects of theconnection request as would be understood by a worker skilled in theart. This configuration information can be indicative of the remotedevice or remote device type, since connection requests by differentremote devices or device types can be configured differently. Forexample, different types of connections can be requested in differentways by different remote devices such as laptops, PDAs, gaming devices,or the like. The information related to the connection request can beforwarded by the network access module to the service access module, theservice access module configured to extract and analyze the informationto obtain further information about the remote device or remote devicetype, for example by comparing the configuration of connection requestinformation against one or more ADPs which relate predetermined profilesor configurations of information to one or more remote devices or remotedevice types typically having said profile. The further informationobtained from this analysis can subsequently be used for authorizationor authentication purposes.

Furthermore, as an alternative to or in addition to configurationinformation obtained during the initial request as described above,information about the remote device can be obtained by running a scriptor query on the remote device. For example, in response to a connectionrequest by the remote device, the service access module can transmit ascript to the remote device (via the network access module), or remotelytrigger execution of a script already on the remote device. The scriptcan be configured to extract and communicate identifying data to theservice access module (again via the network access module). Forexample, a script could obtain and transmit configuration informationabout the web browser application, application version, host operatingsystem, host hardware platform, language, screen size, and the like.This configuration information can be stored and accessed in ways knownto a worker skilled in the art and can be indicative of the remotedevice or remote device type, since different remote devices can beconfigured differently. For example, different remote devices such aslaptops, PDAs, gaming devices, or the like are typically configureddifferently with different hardware and software. In addition, someconfiguration information may not exist on some remote devices,resulting in an error when such configuration information is searchedfor. These errors can also be indicative of the remote device or remotedevice type, since it can be used to explicitly eliminate possibleremote device configurations which would not typically have resulted insuch errors. The information obtained and communicated by the query orscript can be analyzed by the service access module to obtaininformation about the remote device or remote device type, optionally inconjunction with other information, for example by comparing theinformation against one or more ADPs which relate predetermined profilesor configurations of information to one or more remote devices or remotedevice types typically having said profile. The information obtainedfrom this analysis can subsequently be used for authorization orauthentication purposes.

FIG. 12 illustrates an example of extracting information from a remotedevice according to an embodiment of the invention. In step 1210, anetwork connection is requested, for example in response to a useropening a browser on the remote device. The system can respond, in step1220, by forwarding the connection request from the network accessmodule to the service access module, where information related to theconnection request can be extracted as described above. The networkaccess module and service access module can also respond concurrently inother ways, for example by redirecting a browser to an intercept page,and executing processes related to said intercept page to obtain userinformation. In step 1230, a response to the network connection requestis sent from the service access module to the remote device via thenetwork access module. A script, such as a javascript or mobile softwareagent, or trigger for a script existing on the remote device, is sentwith the response. In step 1240, the script executes on the remotedevice to extract information about the remote device as describedabove. Information obtained by the script is transmitted back to theservice access module via the network access module. Informationextracted from the connection request and information transmitted by thescript can then be used for authentication or authorization, for exampleby comparing said information to one or more ADPs to identify the remotedevice or remote device type, and to authenticate or authorize saidremote device or remote device type accordingly.

In one embodiment, Express Authentication can be implemented, whereinuser input is substantially reduced or eliminated during theidentification, authentication and authorization process. In oneembodiment, Express Authentication includes automatic profiling andauthentication and certification of remote devices, for example byuniquely identifying a remote device based on matching selected remotedevice information to information stored in a knowledge base, theinformation being associated with a unique remote device described inthe knowledge base, or by detecting mismatches between selected remotedevice information and information stored in a knowledge base, in orderto deny authentication of a remote device. For example, if substantiallyall of the remote device information reported by a remote device matchesa predetermined selection of remote device information stored in aremote device profile stored in the knowledge base and associated with avalid or authorized user profile stored thereon, Express Authenticationcan be allowed. As another example, if one or more predeterminedportions of the remote device information reported by a remote device donot match corresponding remote device information stored in a remotedevice profile stored in the knowledge base and associated with anauthorized user profile, Express Authentication can be denied.

In some embodiments of the invention, the number and type of attributesof remote device information checked against the database can varyrandomly or deterministically, and in conjunction with previous historyof authentication attempts, to provide efficient and convenient servicewhile maintaining security and integrity of the authentication andauthorization procedures. For example, additional authenticationchallenges, including multi-factor authentication challenges, can beissued or more detailed remote device information attribute analysis canbe performed at random, with probability escalating with the perceivedrisk of fraudulent or unauthorized remote device usage. In someembodiments, Express Authentication can be satisfied by the same user orremote device in different manners, potentially resulting in differentaccess to services.

In some embodiments of the invention, the knowledge base 210 is arelational database. A relational database refers to a type of databasewherein a table stored in the database comprises rows and columns thatare populated with information retrieved from the network access module106 (e.g. access point 108 and gateway 110). In a relational database,there are one or more tables containing stored information, which may beinterrelated through one or more qualified connecting values so thatinformation can be shared between tables.

FIG. 11 provides an exemplary screen shot of such a database, namely aMicrosoft Access™ database comprising sample hotspot, account, andremote device information stored in separate tables with a relationshipconnection to the other tables in the database. This illustration ismeant to provide an example of sample information that could be storedin a database in the context of the present disclosure, wherein varioustypes of information could be retrieved and stored. It will be apparentto the person of skill in the art that other types of database systemsand structures, such as Microsoft SQL Servers or the like, could beconsidered herein without departing from the general scope and nature ofthe present disclosure.

In some embodiments, remote device information is stored in theknowledge base 210 in the form of a remote device profile, generallycomprising an account variable that refers to characteristics of aremote device that allows for recognition and identification of aspecific remote device, which may include, but is not limited to, knownrequirements of that remote device for connecting to the Internet, forexample. In one or more embodiments, remote device information iscollected when a user attempts to access the network via a given networkaccess module 106, or when a user registers for a remote device account,as described below, and is stored in the knowledge base 210 for use inthe authentication of the user and/or remote device when accessing thesystem 10. FIG. 11 provides an example of a remote device profile 1106,in accordance with an illustrative embodiment of the invention.

In some embodiments, user information is stored in the knowledge base210 in the form of a user profile, generally comprising an accountvariable that refers to information about the user retrieved from theuser, including for example, but not limited to, the user's name, acreated username and password, contact information, user type, preferredpayment method and/or means, and the like. In one embodiment, userinformation is collected when a user attempts to access the network viaa given network access module 106, or when a user registers for anaccount, as described below, and is stored in a database for use in theauthentication of the user and/or remote device when accessing thesystem 10. FIG. 11 provides an example of a user profile 1104, inaccordance with an illustrative embodiment of the invention.

In some embodiments, a service profile is stored in the knowledge base210, generally comprising an account variable created by a combinationof one or more of a remote device profile, a user profile, an accounttype, and associated devices. In one example, service profiles aregenerally defined as subscription packages that enable subscribed usersaccess to certain network-based functions and services, such as, but notlimited to, Live TV™ from a home location or online gaming packages, asfurther elaborated and described above. During a registration process,defined in greater detail below, a user may be given options of servicesavailable for each type of remote device functionality. The serviceoptions can be used to limit a user's access to the Internet and/orother networks once the user chooses an option, or to expressly define,disable or enable certain access parameters, for example in accordancewith aspects of relevant service profiles. Consequently, the user canthen pay a predetermined price for the services selected, or have accessto predetermined capabilities for free in conjunction with predeterminedpurchases. In one embodiment, a user can choose different packages fordifferent registered remote devices, or may select one package thatallows access to all the networks with any remote device registered.

In some embodiments, a service profile is associated with a group ofauthorization constraints, authorization whitelist attributes, or acombination thereof. The authorization constraints can specifically denyor block predetermined services or aspects thereof, while authorizationwhitelist attributes can specifically allow or enable predeterminedservices or aspects thereof.

In some embodiments, access to selected functions and services may beextended to all users of a given remote device type, or to all users ofa given group or adhering to a same promotional package or the like,without registration and/or subscription by the user. For example, allusers or remote devices falling within a given category could beentitled to access one or more selected functions and/or servicesattributed to this category without prior subscription or registrationby these users.

In one example, a service profile is defined for a user of a laptop, aSony PSP™, and a Windows Mobile™ PDA, who also occasionally uses asecond laptop, e.g. borrowed from the user's work or elsewhere. The userof the present example could also have a Location Free TV (LFTV) athome, as well as Orb™ on a desktop system. Accordingly, the user wouldbe able to use any of these remote devices on a supported networkalthough there may be restrictions on concurrent usage, for example,wherein only one of each type of remote device can be connected at anytime per account. By registering all the above remote devices andselecting an appropriate service package, the user can be able to accessLFTV on his laptop and PSP™, or using the Orb™ device, access files fromthe user's home computer on his laptop, etc. while at a hotspot accesslocation.

Furthermore, in some embodiments, an upsell feature may also be providedsuch that a user of a given remote device is provided the option toupgrade their current service package to include additional and/orupgraded services. For example, various upsell mechanisms andopportunities may be provided within the present context to provide auser access to additional services, either as a supplement to anexisting subscription package, as a one-time trial or limitedsubscription, and the like. Such upsell mechanisms may be configured tomarket new or supplemental services at various instances during use, forexample upon access to the system, periodically during use, etc., oragain provide such opportunity in response to specific user actions.

For instance, in some embodiments, when a user of a given remote devicehaving restrictive access to the system attempts to access a resourcenot currently permitted by the user's current service profile, forexample as defined by a service profile applied to the user or theuser's remote device, this traffic may be redirected to an interactiveinterface providing the user the option of upgrading or enhancing theirservice profile, for example, for an additional fee. For example, when auser or remote device registered only for gaming services attempts tosurf the Web, an intercept page may be accessed instead proving the userof this remote device the option to upgrade their service profile toenable access to Web surfing functions. Other such examples should beapparent to the person skilled in the art and are thus not meant todepart from the general scope and nature of the present disclosure.

In some embodiments of the invention, the service access module includesa Service Authentication and Authorization Manager (SAAM), which can beconfigured to securely provision and manage users and remote devices onnetworks such as Wi-Fi networks. The SAAM can be configured toauthenticate and authorize users, remote devices, or combinationsthereof, based on user profiles, remote device profiles, and serviceprofiles stored in a knowledge base accessible to the SAAM. The SAAM canfurther be configured to authenticate and authorize users, remotedevices, or combinations thereof based on service provider information,such as promotional use information, location information, timeinformation, or other information as would be understood by a workerskilled in the art.

As an example, authentication can be based on information obtainedthrough use of a stored value card for product or service purchases, byassociating user information related to the stored value card with userprofile information for authentication. For example, user informationrelated to the stored value card can be acquired from a third partymanaging the stored value card. User information related to the storedvalue card can include cash balance information and information onhistory of card use, such as date and location of previous uses.

In some embodiments, the SAAM can be configured to enable ExpressAuthentication, wherein user input is substantially reduced oreliminated during the identification, authentication and authorizationprocess. For example, Express

Authentication can enable instant or one-click secure authenticationbased on stored and automatically transmitted user and remote deviceprofile data. In this embodiment, the SAAM can be configured to collect,authorize, and authenticate a user and/or remote device based on theautomatically transmitted data.

In some embodiments, the SAAM is configured to collect identificationdata, for example automatically transmitted user and remote deviceprofile data, without requiring a client application to be installed orconfigured on the remote device being identified, authenticated, andauthorized. In one embodiment, instead of requiring a specializedapplication operating on the remote device, identification data can becollected on the basis of availability. For example, hardwareinformation, system settings, and information embedded in applicationssuch as Windows™ Update, iTunes™, the YouTube™ application for iPod™, orother applications residing on the remote device can all be sources ofremote device information for providing to the SAAM or otherauthentication or authorization module. As another example, informationcan be extracted from standard communications with the remote device, orrequested through a web browser, SMS service or other nativeapplication, or supplied using a second device carried by the user.

In some embodiments, remote device and/or user information is notautomatically transmitted from the remote device, but is transmitted inresponse to a request or query. For example, a program, software agent,or mobile software agent such as a Java aglet can be transmitted toand/or initiated on the remote device during identification, which,during execution, gathers and transmits user and/or remote deviceinformation to the network access module, service access module, orSAAM. For example, a javascript application can be used to gather andtransmit remote device information in this manner.

Service profile parameters can be dependent on other factors such asdate, time of day, remote device type or remote device class, location,hotspot or business operators or venues, service profiles, simultaneoususage of remote devices by a user, session idle time or timeouts, timefrom expiration of prepaid or introductory service, customer loyalty,payment history, and other factors that would be understood by a workerskilled in the art. For example, frequent or preferred customers, orcustomers who are the focus of a marketing campaign or promotionalpartnership agreement, may be given temporarily enhanced service forbusiness purposes. For example, a service profile may be created orupdated to include additional services for promotional purposes forremote devices associated with particular service providers, when usersof the remote device purchase a product (such as a coffee) in particularhotspot locations. The service profile may indicate for example thatselected services can only be used on the day of purchase at theparticular hotspot location where the purchase was made, and then onlyuntil expiry of a predetermined time period.

It will be apparent that a variety of service packages and upsellmechanisms and strategies may be considered herein without departingfrom the general scope and nature of the present disclosure. As any usermay use anywhere from one to plural remote devices, and that, of one ormore different types of remote devices, the combinations of services,remote device type service access requirements and adaptable servicerestrictions for each or all combination of remote devices can beimplemented using the disclosed system 10 and operational embodimentsthereof.

Access to the features and services considered for in the implementationof the system 10 is generally provided via the identification,authentication and authorization of a user and/or remote device based onidentifying data accessed by the service access module 112 via networkaccess module 106.

In general, a user may access the system 10 once the user, or a remotedevice used thereby, is registered to access the system. In oneembodiment, a user may register themselves, or one or more remotedevices that they intend to use with the system 10, via apre-registration process implemented online, in person, over the phone,or in another manner wherein information relating to the user and/or oneor more remote devices are provided to a system administrator enablingregistration of such identifying information for future use in anauthentication and authorization process. In some embodiments,registration may be performed upon first access, or attempted access tothe system 10 by a user, or by a remote device thereof. Otherregistration strategies, or combinations of pre-registrations,registration confirmations, direct registrations and/or updated (e.g.service upgrade or downgrade) registrations should be apparent to theperson skilled in the art and as such, are not considered to depart fromthe general scope and nature of the present disclosure.

In some embodiments of the invention in which a browser-based or browserchallenged remote device is being used to access a network, the networkaccess module 106, or gateway 110 thereof in the embodiment of FIG. 2C,may intercept the request to access the network 104 and redirect therequest back to the remote device 102 through a web browser for the userto input user information. The information requested can be for example,but not limited to, a username and password. The gateway 110 may alsoforward the request and subsequent communications, if any, to theservice access module 112, where specific remote device information maybe extracted from such communications for the purposes of identifyingthe remote device being used to access the network 104. Such remotedevice information, for example forming part of the remote deviceprofile, may include, but is not limited to, the Media Access Control(MAC) address of the remote device 102, traffic type (e.g. communicationport, data type, communication protocol, traffic headers, etc.), browsertype (e.g. full browser, microbrowser, browser origin and/orconfiguration, etc.), and/or some other unique identifier (e.g. remotedevice configuration, serial number, signature related to a remotedevice clock or crystal oscillator, etc.). The gateway 110 forwards theuser and/or remote device identifying information (user profile, remotedevice profile) from the access point 108 to the service access module112, for example, from where it can be authenticated, for example via aRemote Authentication Dial In User Service (RADIUS) protocol or otherpublic and/or proprietary protocols, to determine whether the user andremote device 102 are registered to access the network.

In some embodiments of the invention in which a browserless remotedevice is used to access a network, the gateway 110 detects the remotedevice request for network access, requests user information to be inputvia a Short Message Service (SMS), and optionally forwards the requestand/or subsequent communications, if any, to the service access module112 where specific remote device information may be extracted from suchcommunications for the purposes of identifying the remote device beingused to access the network 104. Identifying information is then used bythe service access module 112 for authentication to determine whetherthe user and remote device 102 are registered to access the network.

In some embodiments of the invention in which a browser-based,browser-challenged or browserless remote device is used to access thenetwork, the gateway 110 detects the remote device request for networkaccess and forwards the request and/or subsequent communications, ifany, to the service access module 112 where specific remote deviceinformation may be extracted from such communications for the purposesof identifying the remote device being used to access the network 104.The identifying information is then used by the service access module112 for authentication to determine whether the remote device 102 isregistered to access the network.

It will be appreciated that remote device identifying data may beextracted by one or more components of the system 10, namely the networkaccess module 106, the service access module 112, and/or any componentthereof, with proper software, firmware and/or hardware configurations,without departing from the general scope and nature of the presentdisclosure.

In one embodiment of the invention, registration to access the system 10comprise two components: user registration and remote deviceregistration. User registration can occur during the same session as theremote device registration, user registration can occur independently ofremote device registration, either outside the hotspot network through aregistration website, or while accessing the hotspot network.

In one embodiment, registration of a user can result in creation of auser profile stored in a knowledge base, whereas registration of aremote device can result in creation of a remote device profile storedin a knowledge base. Registration of either a user or a remote devicecan also result in creation of a service profile stored in a knowledgebase. User, remote device and service profiles within the knowledge baseare preferably linked for retrieval and association of informationcontained therein.

With reference to FIG. 3, and in accordance with some embodiments of theinvention, when a user registers outside the hotspot network asdetermined at step 302, registration occurs through a web browserinterface. A user enters the website to register for an account. As theuser enters the website, information about the remote device being usedis stored at step 322. The website is programmed to reformat the pagedepending on the type of remote device used and the type of browseravailable at step 323. For example, but not as a limitation to the typeof remote device that can be used, a laptop can use a full browser,whereas a PSP uses a microbrowser. The user selects whether to login orcreate a new account at step 324, depending on whether the user haspreviously set up an account. If the user has not previously created anaccount, the user selects the option to create a new account, and thebrowser is redirected to the new account homepage at step 330, whichdisplays the service options, prices, and procedures available to theuser. The user enters information into a form on the website and thewebsite sends the information to be stored in a database at steps 332 to342. The user enters contact information and selects the services towhich access is desired at steps 332 and 336. The user can register morethan one remote device to be used. The user has the option of paying forthe services selected, which creates a new paid account in a database,or the user can select to use a free trial, and the payment or freetrial option information is stored in the database at steps 338 to 342.Once the account creation is complete, the browser is redirected to theuser homepage at step 318, where the user's service summary isdisplayed, their account verification is requested, and the user canselect to register more remote devices, or choose to upgrade theirservices and select payment options. The user has the option to logoutor connect to the network at step 320, however, since the user is not ata hotspot access point, the user generally chooses to logout.

In some embodiments of the invention, when a user registers whileaccessing the hotspot network, determined at step 302, through abrowser-based or browser-challenged remote device 102, the networkaccess module 106, or access point 108 thereof, (FIG. 2C) recognizesthat the remote device 102 is scanning for a network connection, theaccess point 108 redirects all unauthenticated remote devices to anintercept page for authentication. An intercept page is a webpage thatreceives user login input. While the user attempts to access the networkby logging in using the intercept page, the network access module 106,or the gateway 110 thereof (FIG. 2C) stores information from the userand the remote device being used, for example, but not limited to, username, password, MAC address, browser type, cookie information, etc. atstep 304.

In some embodiments of the invention, when a user registers whileaccessing the hotspot network through a browserless remote device 102,there is provided an SNMP Trap, such as but not limited to the KIWI SNMPTrap, that allows the browserless remote device user to register. TheSNMP protocol is used by network management systems to monitornetwork-attached remote devices for conditions that warrantadministrative attention. The gateway 110 detects what type of remotedevice is being used through key unique attributes of the remote device,for example, MAC address (including manufacturer prefix), host IPaddress, and other properties that can be obtained remotely throughspecial features in the network access module 106, at step 306. Forexample, UTStarcom™ smartphones generally include HTTP headers such as“UA-pixels: 240.times.320” or“x-wap-profile:http://www.htcmms.com.tw/gen/apache-2.0.xml”.

Depending on what type of remote device is detected and/or what type ofbrowser is being used, as explained above, the website willautomatically reformat to suit the type of remote device and/or browserbeing used, at step 308. If the user has already registered for anaccount, and has registered that particular remote device as well, thesystem 10 will recognize the user and remote device and proceed to alogin session at step 310. If the user has previously programmed hisaccount to automatically login (for example in accordance with portionsof Express Authentication), the browser automatically proceeds to theuser's home page at step 312, which displays the user's remote deviceregistration, service summary, and account verification 318. The usercan choose to connect to the available services or logout of the systemat step 320.

If, however, the user has not registered for an account, or has notpreviously registered that particular remote device, the browserproceeds to the login or register new account option at step 324. If theuser has previously registered for an account but has not registered theparticular remote device being used, the user chooses to login at step324, and proceeds to allow the remote device information to be extractedand stored in a database at step 326. The user can choose to save theremote device details to their account, and access the network usingthat remote device, or the user can choose not to save the remotedevice, and is sent directly back to the user home page at steps 326 and328. If the user has not previously created an account, the user is sentto the New Account Home Page, and is required to input contactinformation, select service options, and select payment options tocreate an account, at steps 330 to 342, providing the browserless remotedevice supports such functionality. Otherwise, access is not providedand registration is required via external means, such as describedabove.

Depending on the service and remote device in use, the user may berequired to register themselves and a specific remote device 102 inorder to purchase a connection and/or receive full benefit of theservice. The difference is based mainly on whether the remote device tobe registered is browser-based, browser challenged, or browserless.

Remote device registration is meant to be as comprehensive as possible,and some portion of the registration process may vary from remote deviceto remote device. The user has the option to edit their profileimmediately after logging on to the system through a browser-based orbrowser challenged remote device, for example, the user may add anotherremote device to their profile. Browserless remote devices, however, aregenerally more limited in what applications and information they may beprovided access to, based for example, on their user interfacingcapabilities.

In some embodiments of the invention, when a user enters a hotspot areawith a browser-based or browser-challenged remote device 102, after theuser has created a registered account in the system 10, as describedabove, the access point 108 sends an intercept page requiring the userto input their user name and password, or only their password, or otherinformation that can be used to identify the user. Once the user hasinput their information into the browser form, the information is sentthrough the network 104 to be compared with valid user informationstored in the service access module 112.

In some embodiments of the invention, when a user enters a hotspot areawith a browserless remote device 102, after the user has created aregistered account in the system 10, as described above, the accesspoint 108 uses a SNMP Trap to collect the user information and send itthrough the network 104 to be compared with valid user informationstored in the service access module 112. In addition, depending onremote device and/or user registration settings, an optional request foruser information and/or confirmation may be communicated to a distinctremote device of the registered user for confirmation. For example, aconfirmation message could be sent to a user's cellular phone, or othersuch device, via a Short Message Service (SMS), wherein the user maythen confirm via this distinct device that they are in fact attemptingto access the system via their browserless remote device. In thisscenario, this would allow a user to identify an event where access tothe system is being erroneously and/or fraudulently attempted usingtheir remote device and/or remote device identity.

In some embodiments of the invention, when a user enters a hotspot areawith a browser-based, browser-challenged, or browserless remote device102, after the user has created a registered account in the system 10,as described above, the gateway 110 retrieves specific remote deviceinformation from the remote device and sends that information throughthe network 104 to be compared with valid remote device informationstored in the service access module 112.

There are many different remote devices 102 that may be used with thesystem 10. To accurately identify a remote device there may be a numberof different pieces of information needed to be retrieved from theremote device. The MAC address of the remote device is an example of onepiece of information that can help identify a remote device, however, itmay not be sufficiently robust, as spoofing is possible and quite simpleon some platforms with the proper tools. Depending on the securitylevels expected from implementation of the system 10, using simpleremote device identification methods such as using the MAC address maybe sufficient.

In an embodiment where one seeks to reduce or avoid MAC address spoofingproblems, other pieces of information may be available to help identifya remote device and can be retrieved by the gateway 110 while the remotedevice is attempting to access the network 104 through the access point108. For example, some of the information that can be retrieved from aremote device that can help uniquely identify it include, but are notlimited to the following: MAC address (including manufacturer prefix),browser characteristics, operating system characteristics, host IPaddress, traffic headers, clock or crystal oscillator characteristics,serial numbers, and other properties that can be obtained remotelythrough special features in the network access module 106.

Using identifying data provided by the user, and/or providedautomatically by the user's remote device, the service access module 112proceeds to the authentication of the user and/or remote device. In someembodiments, authentication is intended to be user-centric, for example,a user with a valid account should be able to connect to the network 104and access those services for which he has subscribed (which may includeall services available in a wide open access system), on whicheverremote device 102 he happens to be carrying at that moment, oralternatively, for which remote device registration has beenimplemented. The characteristics of the remote device 102 and/orapplication attempting to connect to the network 104 can factor into themechanics of the authentication process, and as such, the system 10 canbe configured to address these factors.

In one embodiment of the invention, authentication is intended to bedevice-centric, for example a remote device which is associated with avalid account should automatically or semi-automatically connect to thenetwork through a hotspot once it becomes available. For example,Express Authentication can be used to connect a registered remotedevice, possibly including prompting a user to confirm said connection.

In one embodiment, a RADIUS is used as an authentication, authorization,and accounting (AAA) protocol. Such a protocol is commonly known in theart and used for applications such as network access or IP mobility. Foraccess to a network to be granted, the information input into the remotedevice web browser or retrieved by the SNMP Trap, depending on whatremote device is being used, is passed through the network access module106 (e.g. the access point 108 and gateway 110 of FIG. 2C), to a RADIUSserver operatively coupled to or integrated within the context of theservice access module 112, over the RADIUS protocol. For example, aNetwork Operations Center (NOC) authentication request can cause anaccess-request to the RADIUS database which will return an access-acceptor access-reject status. In general, the RADIUS server checks that theinformation is correct using authentication schemes such as PasswordAuthentication Protocol (PAP), Challenge-Handshake AuthenticationProtocol (CHAP), or Extensible Authentication Protocol (EAP). Ifaccepted, the server will then authorize access to the ISP system andselect an IP address. If the username and password are correct, RADIUSwill return the length of time remaining for the account and the name ofthe access list to use. If the account has time remaining and is notdisabled, the remote device is authenticated and the access list isenforced by the access point 108. In one embodiment, the access list iswhat defines what a remote device can or cannot do while connected tothe access point 108. The individual definitions are stored in RADIUSbut loaded to the access point daily, for example, the RADIUS serverwill also be notified if and when the session starts and stops, so thatthe user can be billed accordingly.

In order to have control and flexibility over authentication andauthorization, a RADIUS database may be used by the service accessmodule 112 to provide the same programmatic potential as a proprietarylocal knowledge base could. The RADIUS database can contain access listsassociated to the different service packages provided as describedabove. These advanced authentication methods allow authenticationthrough means that extend beyond the traditional client or browser-basedmethods, allowing more remote devices, for example, browser challengedor browserless remote devices to connect and reconnect at publichotspots.

In some embodiments, the advanced authentication methods can allowdifferentiated authorization based on identification and authenticationdata, as well as other factors. For example, different users, remotedevices, remote device types or remote device classes can be offereddifferent services or different aspects of a service profile can beapplied based on information about the remote device, location, time ofday, service providers, payment, purchase of related products, servicecontracts, and other information as would be understood by a workerskilled in the art.

In some embodiments of the invention, the access point 108 is configuredto send an ‘Association Success’ trap to a remote Simple NetworkManagement Protocol (SNMP) client allowing for authentication of remotedevices 102 that do not invoke an intercept page, for example,browserless remote devices. SNMP is used by network management systemsto monitor network-attached remote devices for conditions that warrantadministrative attention. SNMP is used to collect interface informationfrom remote devices 102. A person with ordinary skill in the art wouldrecognize how SNMP traps are used to collect information from remotedevices 102 and connected to a network 104 through an access point 108.For example, the remote device interface information can be passedthrough the gateway 110 to the RADIUS database, as described above, toacquire authentication.

In one embodiment of the invention, the access point 108 is alsoconfigured to receive a request, for example, a Hypertext TransferProtocol using Simple Object Access Protocol (HTTP SOAP) call, toretrieve the remote device IP address assigned by the access point 108.An HTTP SOAP call is an HTTP message that complies with SOAP encodingrules. A person of ordinary skill in the art would recognize that theHTTP SOAP call is only an example of a way of sending and receivinginformation over a network. The IP address of the remote device 102 can,for example, be associated with the remote device MAC address forenhanced authentication.

In one embodiment of the invention, multiple SNMP clients are used, asdescribed above, to provide scalability for concurrent remote deviceauthentication and can be extended to support a global solution wherehigh latency is required by the access point 108 during authentication.For example, a Kiwi SNMP client may be used to filter and/or parsemessages and take actions using script. Using a scripting language, suchas, but not limited to, JavaScript, a script file can be created toparse a SNMP message to extract information passed from the remotedevice 102 through the access point 108 via the SNMP trap, remote deviceinformation such as, but not limited to, the MAC address, the remotedevice IP address, or the server IP address. Once extracted, theinformation can be sent for authentication. In one embodiment, thisprocess may be done asynchronously to avoid bottlenecks of SNMP messagesin the SNMP client(s).

In one embodiment of the invention, a webservice is used to communicate,for example, SNMP messages from one remote device to another through anetwork. A webservice is an application programming interface (API) thatallows information to pass through one or more networks that may beusing different communication protocols.

An example of an Authentication Webservice API could be designed toinclude the following elements: a AccessPointlnformation function,AuthenticateDevice function which Encapsulates the HTTP request made forNOC authentication, a ConnectionInformation function, aDeauthenticateDevice function which Encapsulates the HTTP request madefor NOC deauthentication, a DeviceAssociated function which providesremote device identification and validation prior to authentication, anda DeviceDisassociated function which provides remote deviceidentification and validation prior to deauthentication.

In this example, a DeviceAssociated method is called from the SNMPclient. The request is first added to a queue to wait for processing.This may be beneficial if multiple SNMP clients attempt to authenticatethe same remote device association, and can reduce the number of NOCauthentication attempts to the access point 108. Upon a successfulauthentication the duplicate authentication requests are removed fromthe queue.

Continuing with the above example, after queuing individual requests,the parameters are then verified and corrected if necessary. Thefollowing process checks are done:

-   -   1. Is the gateway using a Virtual Private Network (VPN)? This is        determined through a lookup in a VPN database. The VPN database        is populated through a custom built script that is invoked for        all connects and disconnects to the VPN.    -   2. Is the remote device IP address available? As discussed        above, if the remote device IP address is not available through        the SNMP trap used, then a HTTP SOAP call can be done to the        access point 108 using the MAC address to retrieve the remote        device's assigned IP address.    -   3. Is the remote device registered? Using the MAC address, a        lookup is done in the service access module 112 that stores the        user and/or remote device information, to locate the account        that the remote device belongs to where the account can contain        the RADIUS credentials, for example, the username and password,        required for NOC authentication.

With regard to this example, once all parameters are verified andcomplete, the NOC authentication to the access point 108 is performed.The NOC authentication can be performed using, for example, an HTTPScall to the access point 108 with the required parameters, and theresult is returned as a pass, fail, or error value. Access to selectedservices can be based on the result. For example, if the result isreturned as a pass, access can be granted, whereas if the result is afail or error value, access is not granted, and optionally theauthentication procedure can be retried.

In one embodiment of the invention, the Advanced Device Profile (ADP) isstored in a knowledge base and used for authentication purposes.

In one embodiment, Express Authentication can be implemented usinginformation stored in a knowledge base.

With an authentication system including multiple components,encompassing many different technologies, and spreading across multiplegeographical locations, it may be effective to have a single and simplemeans to trace processing sequentially across all components fordebugging and analytical purposes. A tracing webservice allows traceinformation to be sent unobtrusively as authentication moves through theprocess. A webservice, because of its interoperable characteristics andwide programmatic support among technologies, is one possible way totrack the system process.

According to embodiments of the invention, authorization occurs once theremote device 102 and/or user have been authenticated, as describedabove. The system 10, via the network access module 106, or gateway 110thereof (FIG. 2C), restricts the user and remote device to actionsdetermined by the remote device's capabilities and/or the servicepackage purchased by the user, as described in more detail below, bysetting up firewalls, allowing or blocking specified TCP or UDP ports,filtering or restricting network traffic based on type, packet headers,content, flow characteristics such as rate, delay and variation thereof,source, destination and/or other access limitation rules to beimplemented by the system 10. If the user selects the wide-open Internetaccess option, the user will have full access to the Internet, forexample. Authorization can also operate by expressly allowing a userand/or remote device to carry out predetermined actions or connect topredetermined services, instead of specifying what actions are notallowed. The sets of allowed or restricted actions are described by aservice profile, including for example authorization constraints orauthorization whitelists.

In one embodiment, service profiles are dependent on factors such as theamount of time a user is accessing an application, the type or contentof the application, rate and volume of data downloaded or uploaded, orother factors related to application usage. These factors can be inaddition to other factors, such as allowing access to specifiedapplications, to specified remote devices or remote device types, or atspecified locations, times, or the like.

In another embodiment, service profiles can be configured to enable ordisable selected applications or groups of applications, either directlyaccording to application name or type, or indirectly by setting minimumor maximum service levels for selected services such as bandwidth,delay, enabled or disabled TCP or UDP port numbers, firewall settings,and the like, where said service levels are required for certain degreesof performance of selected applications, to which a value may beassociated. These factors can be in addition to other factors, such asallowing access to specified applications, to specified remote devicesor device types, or at specified locations, times, or the like.

In one embodiment, in order to influence or control access toprespecified applications or services, different applications orservices can be profiled. To profile an application or group ofapplications, the type and level of communication resources associatedwith usage of said application or group of applications is determined,such as TCP or UDP port usage, bandwidth, packet size, trafficcharacteristics, and the like. This association can be performed throughcontrolled experimentation or monitoring of customer activity. Theassociation between applications and type and level of communicationresources is then stored in an application profile in a knowledge base.The application profile can subsequently be used to substantiallymonitor and/or restrict users to predetermined applications or groups ofapplications by monitoring and/or restricting access or usage to theassociated types and levels of communication resources. Profiling ofapplications can be performed automatically according to an adaptive orautomated procedure, or by a network administrator, or by a combinationthereof.

In an optional embodiment of the invention, the system 10 uses a valuebased application (VBA) which provides limited access to an exclusiveapplication, service, or remote device connection, or a combinationthereof, that is packaged, marketed, and sold at a hotspot at a pricerepresentative of its perceived value, which is discounted fromwide-open Internet access that is currently provided.

Using VBA service profiling, the system 10 can be configured to identifyincoming traffic substantially without user input, recognize returningusers and remote devices by type, connect users with a single click, orno clicks, such as by Express Authentication, and apply rulespost-authentication to allow only that type of remote device, or aservice on that remote device, to connect. By possessing thisfunctionality it is possible to assemble creative packages of serviceofferings which allow users to pay for only the services they will use.Alternatively, users can obtain some services for free, or obtainservices at no charge or at a reduced price when another good or serviceis purchased. In this way, targeted marketing can also be performed inconjunction with user services in embodiments of the invention.

In one embodiment, service profiles can be applied to determine whatservices to connect a user to, and the conditions required for eachservice. Service profiles can restrict, allow, or otherwise configureaccess to applications based on various factors. For example, serviceprofile parameters can pertain to date and time ranges, remote devices,remote device types or remote device classes, for example as indicatedin remote device profiles, geographic locations, hotspot or businessentity identification, types of VBA services available, number of usersaccessing services, available bandwidth, concurrent use of multipleremote devices by a user or group of users, session idle time ortimeouts, or other parameters affecting access to services, applicationsor VBAs as would be understood by a worker skilled in the art.

In one embodiment, service offerings can be related to providing accessto one or more applications under predetermined time, quality, or otherrestrictions. Service offerings need not be identified with a particularapplication, but can be defined by potential combinations of serviceprofile parameters such as authorization constraints or authorizationwhitelists. For example, a communications service provider A and aninternal access service provider and product vendor B could devise aproduct whereby users of remote devices affiliated with A, who alsopurchase a product or service from B using a stored-value card, couldget 1-hour free open Internet access through B at selected vendorlocations on the day they make the purchase. Another communicationsservice provider C could offer users of remote devices affiliated with Cfree access (or access for a nominal charge, or free access with anotherpurchase) at selected hotspots to their Facebook account, provided theusers have purchased a qualifying service plan.

Once logged into a profile, for example through an access managementmodule, the user can have the option to, among other functions, addremote devices. Upon selecting a remote device, the user entersinformation required to register that particular remote device intotheir account. Once registered, the user selects the service packagethat suits his needs, and selects a payment option, and then the usercan use the remote device at any hotspot access supported by system 10.

In one example, the VBA constructions define specific gateway firewallrequirements for each product. By identifying settings of the servers,transports, or ports used by the remote devices and services supportedby the system 10, which may include for example, but are not limited tocomputing devices, games, streaming video products, collaborativebusiness applications, social applications, etc. In one embodiment,there are created Access Control Lists (ACLs) that provide proper accesssupport for each VBA, while restricting access to other common servicesfor which the user has not paid. These restrictions may occur at thegateway 110 level, for example, using firewalls to limit access tocertain Internet and other network capabilities.

In another embodiment of the invention, the restriction of networkaccess may occur through funneling all user traffic through a centralproxy server. This method of limiting network access according to a VBAwould allow for more control, for example, of the authorization process.

In one embodiment, in order to create limited-access VBA profiles, asdescribed above, Internet access requirements for each of theapplications to be supported including servers, ports, protocols, etc.which could be used by a remote device during the execution of a certainapplication are identified. For example, a game on the Nintendo DS™ mayrequire access to a Nintendo™ server, over TCP, using port 1025 outboundand 1030 inbound. An inventory for each application's connectivityrequirements is used in order for the applications to be combined intoproduct packages, the VBAs, and their requirements combined. The amalgamof the requirements for each package form the basis for firewall rulesfor a specific VBA. These application profiles contain information aboutvarious characteristics of each application or remote device whichdescribe not only how the application behaves on the Internet, butunique characteristics of the remote devices which would allow instantand automatic detection of the remote device type and link a specificremote device to a unique user. These application profiles can comprisea dynamic database. For example, with new applications and remotedevices being introduced, constant updating may be implemented tosupport new remote devices, and to ensure that users do not haveproblems with a new software program or application on older remotedevices.

To restrict and/or prohibit access to all other available services theuser did not select, for example, a user who pays for online gamingshould not be able to browse the Internet or send email, requires aproper set of firewall rules for any VBA, by permitting everythingrequired for that VBA to function, and blocking access to everythingelse. These firewall rules can be established based on transportprotocols (e.g. TCP, UDP, ICMP, etc.), destination server (e.g. IP orDNS name), port number, traffic protocol (e.g. SMTP, FTP, HTTP, etc.),header information, etc. By combining a set of permitted servers, ports,protocols, and the like and restricting others, the firewallconfiguration for any one VBA can be determined.

In one embodiment of the invention, to facilitate thepost-authentication user restrictions at a hotspot, manipulation of thefunctionality of the gateway 110 provided is desirable. For example,some manipulation of the “access-list” attribute, which is avendor-specific attribute used by the Colubris™ Multi-Servicecontrollers (MSC-3200), could be used. Allowed and disallowed IP addressand port combinations can make up an access-list definition which isassociated to an account/remote device combination and enforced by theaccess point 108.

An example of such manipulation of an “access-list” attribute isdescribed in the following steps:

-   -   (1) determining in advance a selection of packaged VBAs, and the        firewall rules needed to operate them;    -   (2) establishing those rules in the start-up profile of the        network access module 106 (e.g. gateway 110) in the form of an        “access-list” such that each time the unit connects to the        Internet, or at a given refresh rate (e.g. once per day), it        would download instructions for “DS Gaming”, “PSP”, etc.; these        instructions could be read into memory by the gateway 110, but        not applied, for example, until called by a user connection; and    -   (3) upon login, programmatically determining the subscribed VBA        for that user; and 61] (4) calling the appropriate access-list        profile for that user and activating it at the gateway 110 for        that session.

The remote device profiles for each service package can be stored in adatabase (e.g. knowledge base 210 of FIG. 2B), and combined with one ormore user profiles, a list of associated remote devices, a list ofservice subscriptions, or a combination thereof, to form a serviceprofile for that user or remote device, as described above. When a userlogs in, or a remote device 102 is recognized at the time of connection,the system 10 is able to look up the service profile for that userand/or remote device, determine the appropriate level of access, andapply the profile to the current connection by configuring theappropriate firewall rules at the gateway 110 following authentication.

As will be appreciated by the person of skill in the art, the system 10may further comprise a reporting module used by network accessproviders, and other partners, for reporting data related to systemusage analysis and billing purposes. Reports may include informationregarding, for example, usage by user, location and vendor; usage byremote device type; payment type; and other such information, as wouldbe apparent to the person skilled in the art.

It will be further appreciated that various upsell mechanisms, asdescribed above, may be implemented so to actively upgrade a user's, ora remote device's service access package while interfacing with thesystem.

With reference to FIG. 4, and in accordance with one embodiment of theinvention, there is shown a flowchart providing a process foridentifying, authenticating, and authorizing a user utilizing abrowser-based or a browser challenged remote device 102 to access anetwork 104. In this example, the remote device 102 scans the area foran available network connection. The user invokes a web browser viawhich a given Internet resource may be requested at step 402. Thegateway 110 intercepts the request and redirects it to the networkinterface at step 404. The gateway 110 also sends through the networkthe remote device characteristics that it has extracted from the remotedevice 102 at step 404. The network interface receives the request toaccess the network and the remote device information and sends therequest on to an Access Management Module (e.g. of service access module112 of FIG. 2B) at step 406. The Access Management Module captures theremote device and user information and analyzes the remote devicecharacteristics to determine what information the gateway extracted atstep 408. The remote device information is cross-referenced with thedatabase containing user, remote device, and service profiles at step410. The Access Management Module determines what type of remote deviceis being used to access the network and reformats the User Interface(UI) to suit the remote device's capabilities at step 412. At step 414,the process determines whether the user is known. If the userinformation was sent with the request, the Access Management Modulesends that information to the database to retrieve the user's accountdetails at step 420. If the user information was not sent with therequest, the intercept page is sent to the remote device so the user caninput their user information at step 416. The user's information is sentback to the Access Management Module at step 418 and the information iscross-referenced with the account details in the database to verify theuser has an account at step 420. The database determines what serviceprofile the user has access to through the current remote device theuser is using at step 422. The process sends the available serviceoptions to the remote device through an appropriate UI at step 424, andthe user selects which services to allow at step 426. The processselects the appropriate service credentials and restrictions at step428, and sends that information through the network interface at step430, to the gateway to enforce those restrictions at step 432. The useris granted access to the network limited to the service profile the usersubscribed to at step 434.

With reference to FIG. 5, and in accordance with one embodiment of theinvention, there is provided a sequence diagram providing a process foridentifying, authenticating, and authorizing a user to access a networkinterface 508 using a browser-based or browser challenged remote device502. The user, via the remote device 502, sends a URL request to accessthe network (step 514), the gateway intercepts the request and redirectsthe request back to the user via an intercept page (step 516). The userinputs user information through the form provided on the intercept page,and this information is sent to the Service Access Module, wherebyremote device characteristics may be further extracted from remotedevice communications, for use by the Access Management Module 510 (step518). The Access Management Module 510 first looks up the remote devicecharacteristics in the database 512 (step 520) for a matching remotedevice profile stored in the database 512. The database 512 sends theremote device profile back to the Access Management Module 510 (step522). The Access Management Module 510 then looks for an account profilethat matches the remote device profile to compare user information (step526). Once an account profile is found, the process formats the UserInterface (UI) to suit the remote device being used (step 528) and sendsa web page displaying available service options for that user and remotedevice to the user so the user can select the required services. Theuser selects the required services and selects payment options, and thatinformation is sent back to the Access Management Module 510 (step 530)to be cross-referenced with the service profiles stored in the database512 (step 532). A service profile is selected and the service profilerules are sent to the Access Management Module (step 534). The user'scredentials in the RADIUS database are updated, and the rules of theservice profile are associated with the credentials (step 536). Theremote device information is sent back to the gateway 504 to initiateauthentication of the remote device 502 for the services selected (step538). The gateway 504 makes a RADIUS request to authenticate the remotedevice for the services selected (step 540). The RADIUS server checksthe credentials and retrieves the associated service profilerestrictions (step 542). The RADIUS sends an “accept” message back tothe gateway 504 (step 544), accompanied by the service profilerestrictions to be enforced by the gateway 504. A network session iscreated (step 546) and the user can establish a connection to thenetwork 508 (step 548).

With reference to FIG. 6, and in accordance with one embodiment of theinvention there is shown a flowchart providing a process foridentifying, authenticating, and authorizing a user utilizing abrowserless remote device 102 to access a network 104. The remote device102 scans for an available network connection at step 602. The gateway110 detects the remote device scanning for a network at step 604, andforwards the remote device information to the Access Management Moduleto be extracted thereby. The Access Management Module captures andanalyzes the remote device characteristics to determine which remotedevice is being used to access the network at step 606. The remotedevice characteristics are cross-referenced with remote device profilesstored in a database at step 608. The database is also searched for theuser account profile, if one exists, at step 610, and it is determinedwhether the user has previously programmed the account profile toauto-authenticate when the user accesses the network at step 612. If theuser has not selected to auto-authenticate, the authentication servicerequests confirmation from the user at step 614. The user provides userinformation to confirm user account information using Short MessageServices (SMS) which are text messages that can be sent using devices,such as but not limited to, cell phones and pocket PCs, at step 616. Theuser information received from the user and remote device 102 iscross-referenced with service profiles established for the account andremote device profiles which are stored in a database 112 to determinethe appropriate services to make available at step 618. The AccessManagement Module determines the credentials and restrictions of theselected service profile and sends those to the authentication serviceat step 620. The authentication service verifies the user account,remote device, and service profiles and grants network access to theuser at step 622. The gateway provides the enforcement of the serviceprofile to allow the user to only access services provided for theremote device they are using at step 624. The user is providedrestricted access to the network in accordance with the services theuser has provided payment for at step 626.

With reference to FIG. 7, and in accordance with one embodiment of theinvention, there is shown a sequence diagram providing a process foridentifying, authenticating, and authorizing a user utilizing abrowserless remote device 102 to access a network 104. A user 702 at ahotspot access location turns on a browserless remote device 704, forexample, but not limiting to, a mobile phone (step 716). The remotedevice attempts to make a radio access network (RAN) connection to theavailable network (step 718). The gateway 706 creates a SNMP trap toextract remote device information from the remote device (step 720). TheSNMP “device associated” notification is sent from the SNMP Server 710to the Access Management Module 712 (step 722). The Access ManagementModule 712 cross-references the remote device characteristics with theremote device profiles stored in the database 714 (step 724). Once aremote device profile is established, the Access Management Module 712looks in the database to see if there is an account profile associatedwith the remote device profile (step 728). The account profile detailsare sent from the database 714 to the user 702 requesting the user toconfirm the account details (step 732). The user provides userinformation to confirm the account details through SMS, for example, andthe information is sent back to the Access Management Module 712 (step734). The Access Management Module 712 looks in the database 714 toacquire the appropriate service profile for the user and remote device(step 736). The appropriate service profile is selected from thedatabase 714, and the service rules are sent to the Access ManagementModule (step 738). The user's credentials in the RADIUS database areupdated, and the rules of the service profile are associated with thecredentials (step 740). The remote device information is sent back tothe gateway 706 to initiate authentication of the remote device 704 forthe services selected (step 742). The gateway 706 makes a RADIUS requestto authenticate the remote device for the services selected (step 744)while a connection is established with the remote device (step 746). TheRADIUS server checks the credentials and retrieves the associatedservice profile restrictions (step 748). The RADIUS sends an “accept”message back to the gateway 706 (step 750), accompanied by the serviceprofile restrictions to be enforced by the gateway 706. The gateway 706then initiates a session (step 752) feeding back to the accessmanagement module (step 752).

With reference to FIG. 8, and in accordance with one embodiment, thereis provided a flowchart of steps taken when a user attempts to access anetwork at a hotspot location, using a browser-based remote device. Theuser enters the hotspot location, and turns on the remote device, theremote device scans for available networks, and the user opens a webbrowser at step 802. The user selects whether to have full access to thenetwork or to have a service package option, at step 804. If the userchooses to have full access to the network, the user selects the connectoptions provided by a carrier at step 806. The gateway initiatesauthentication of the user through the use of RADIUS at step 808. Thegateway confirms whether the user is a valid user at step 810, if theuser is authenticated, the user is given options to connect additionalremote devices to the network at step 812, which would then forward themto the service package options provided at step 834. If the user choosesnot to connect additional remote devices to the network, the user isconnected to the Internet with wide open access at step 814.

If, at step 804, the user chooses to have access to the network based ona service package, the system attempts to recognize the remote devicebeing used to access the network at step 816, if the remote device isrecognized, the user is prompted through the web browser to input userinformation or the user can select to auto-authenticate, at step 818. Ifthe user is a valid subscriber, as determined at step 820, the userprofile is passed to the hotspot network access at step 822. The gatewayinitiates the authentication of the user, remote device, and serviceprofiles at step 824, and allows the user to have access to the networkfor the services selected in the service package at step 826. If theremote device being used is not recognized at step 816, the user isprompted to login or create a new account using the web browser at step828. If the user has previously registered an account, the user logs on,and the remote device characteristics are then stored in a remote deviceprofile associated with that user at step 830.

If the user is a new user, they are required to create a new account atstep 832. The user selects the type of service package, and paymentoption from the list displayed at step 834, and the account is created,and updated at step 836, and the remote device being used can then beconnected to the network at step 838. The account information is sent tothe hotspot network access at step 822, and the gateway initiates theauthentication of the user, remote device, and service profiles at step824, and allows the user to have access to the network for the servicesselected in the service package at step 826.

With reference to FIG. 9, and in accordance with one embodiment of theinvention there is provided a flowchart of steps taken when a userattempts to access a network at a hotspot location, using a browserchallenged remote device. The user enters the hotspot location, andturns on the remote device, the remote device scans for availablenetworks, and the user invokes a web browser at step 902. The serviceaccess module extracts information from the remote device to determinewhether it is a registered remote device, at step 904. If the remotedevice is not a registered remote device, the gateway receivesinformation from the user to determine if the user has a valid accountat step 906. The user's information is sent to be authenticated at step908. If the user is verified as a valid user, the remote deviceinformation is then stored as an associated remote device at step 910.If the user's service package already provides sufficient access to thenetwork for that particular remote device, the user can connect to thenetwork, or the user has to select service options from a list displayedon the web browser at step 912. The account information is sent to thehotspot network access at step 914, and the gateway initiates theauthentication of the user, remote device, and service profiles at step916, and allows the user to have access to the network for the servicesselected in the service package at step 918.

If the remote device is already registered to an account as determinedat step 904, the user inputs user information at step 920 If the userinformation is valid, the user can select to auto-connect at step 922,or require the system to ask the user whether they wish to connect atstep 912. The account information is sent to the hotspot network accessat step 914, and the gateway initiates the authentication of the user,remote device, and service profiles at step 916, and allows the user tohave access to the network for the services selected in the servicepackage at step 918.

If it is determined at step 906 that the user does not have a valid useraccount, the user creates a new account at step 924. The remote deviceis registered to the user's remote device profile at step 926, and thelist of service options is displayed at step 928.

The account information is sent to the hotspot network access at step914, and the gateway initiates the authentication of the user, remotedevice, and service profiles at step 916, and allows the user to haveaccess to the network for the services selected in the service packageat step 918.

With reference to FIG. 10, and in accordance with one embodiment of theinvention, there is provided a flowchart of steps taken when a userattempts to access a network at a hotspot location, using a browserlessremote device. The user enters the hotspot location, and turns on theremote device, the remote device scans for available networks, and theuser begins a text message session and uses a radio access network toconnect to the network, at step 1002. The gateway determines whether theuser is a recognized user at step 1004. If the user is recognized, it isdetermined whether the user has a registered account at step 1006. Ifthe user has a registered account, it is determined whether the user hasa valid service subscription for the remote device being used at step1008. If the user has a valid subscription for the remote device beingused, the account information is sent to the hotspot network access atstep 1010, and the gateway initiates the authentication of the user,remote device, and service profiles at step 1012, and allows the user tohave access to the network for the services selected in the servicepackage at step 1014.

If it is determined at step 1006 that the user is not a registered user,the system checks if the connection available to the remote device istime limited at step 1016, if it is time limited, the system checks ifthe remote device being used has time available at step 1018. If theremote device has no time available, the user will not be allowed toconnect to the network (step 1020). If the connection available is timelimited, and the remote device has time available, the limited remotedevice profile is sent to the hotspot network access at step 1026, andthe gateway initiates the authentication of the remote device at step1028, and allows the user to have access to the network for the limiteddevice-specific services at step 1030. If the connection available isnot time limited at step 1016, the open access to the device-specificnetwork connection is sent to the hotspot network access at step 1032,and the gateway initiates the authentication of the remote device atstep 1034, and allows the user to have open access to the network forthe device-specific services for an unlimited amount of time, at step1036.

If it is determined at step 1004 that the user is not a recognized user,the remote device characteristics are extracted and stored as a remotedevice profile in a database at step 1022. The remote device attempts toconnect to the available network for device-specific access, at step1024 if the connection available has a time limit the limited remotedevice profile is sent to the hotspot network access at step 1026, andthe gateway initiates the authentication of the remote device at step1028, and allows the user to have access to the network for the limiteddevice-specific services at step 1030. If the connection available isnot time limited at step 1024, the open access to the device-specificnetwork connection is sent to the hotspot network access at step 1032,and the gateway initiates the authentication of the remote device atstep 1034, and allows the user to have open access to the network forthe device-specific services for an unlimited amount of time, at step1036.

The above provides for different examples in which device-identifyingdata can be used to not only manage wireless network access at differenthotspot locations by remote devices at such locations, but also touniquely recognize and optionally track and report on device activity byway of the creation and management of a device profile uniquelyassociated with such devices and stored in a network accessibleknowledge base. Accordingly, and as described above within the contextof system 10, devices interfacing with a network access module 106 orWAP 108 at a given hotspot may, in some embodiments, be automaticallyidentified and recognized by the system 10. Namely, a unique deviceidentifier is automatically embedded within a device transmissionwithout user input and thus communicated by the device to this WAP 108.Upon cross-referencing this device identifier with device profilesstored at a common knowledge base 210, a match can be made and thedevice ultimately recognized. Upon identifying an unrecognized device, anew device profile may be created from the unique device identifierextracted from communications received from this unrecognized device,thus allowing for subsequent recognition, and thus optionally tracking,of this particular device. From these compiled device profiles, deviceusage patterns (usage time, location, etc.) can be logged and reported,for example.

Within this context, a given device can be recognized as a returningdevice when subsequently identified at a same location, thus indirectlyidentifying the user of this device as a potentially frequent or loyalcustomer. Similarly, a given device may be recognized uponidentification at one of multiple hotspot locations having common accessto the network accessible knowledge base. In one such embodiment,frequent or loyal customers (or at least their device), can berecognized across multiple hotspot locations, for example grouped orotherwise associated with a common operator, brand, business entity, orthe like. Various applications, such as the tracking and reporting onrepeat devices, the provision of improved services or offerings to suchrepeat devices, and other such applications as exemplified below, may bederived from the ability to identify and recognize devices acrossmultiple hotspot locations, in some embodiments, without user input,that is in some cases, unbeknownst to the user of the device.

FIG. 13 provides another example of a system 1300 generally configuredto provide remote devices 1302 access to network services, such as theInternet, from a public hotspot 1306 or the like. In this particularexample, the system 1300 is configured to authorize full accessprivileges to authenticated users, though it will be appreciated thatrestricted access or access to only some services may also beconsidered, as described above, within the context of this example.

In this particular example, the device recognition and tracking featuresof the above-described embodiments are further exemplified. Namely, thesystem 1300 is generally subdivided into a detection component 1320,whereby remote devices 1302 in the vicinity of a given hotspot 1306 maybe detected and automatically identified by way of a unique deviceidentifier automatically embedded within a device transmission, and adata engine component 1322 for processing device identities, optionallyin combination with time and location data, to provide for devicerecognition, tracking and other such features, as introduced above andas further exemplified below. In this particular example, the detectioncomponent 1320 comprises a hotspot radio receiver 1306, such as a WAP orother such wireless sensor, which receives wireless transmissions fromthe devices 1302 in its vicinity and communicates these transmissions toa centralized controller 1310 (e.g. via a gateway). The controller 1310(an example of which may include, but is not limited, to an Aruba 3200Controller) is generally configured to relay raw transmissions receivedby different hotspot sensors 1306 to a listener 1312, which generallycomprises one or more dedicated software modules that extract one ormore unique device identifiers from these transmissions for usedownstream in identifying and recognizing devices during subsequentvisits at a same or other hotspot associated with system 1300. In thisparticular embodiment, the listener 1312 is generally characterized as apacket listener (e.g. implemented in the context of packetcapture—PCAP), but may also be characterized as a Real Time TrackingSystem (RTLS) processor in which an RTLS data stream is processed toextract similar data, and optionally, provide access to signal strengthdata in further characterizing proximity of an identified device. Othersuch listeners currently available or that may evolve in the field toprovide similar functionality will be understood to fall within thegeneral scope and nature of the present disclosure. In some embodiments,the unique device identifier comprises a value representative of aninherent characteristic of the device, such as a MAC address, that isautomatically embedded within device transmissions without user input,and in most cases, unbeknownst to the user. Namely, the uniqueidentifier extracted by the system 1300 is generally specific to thedevice itself and not pre-designated for the purpose of wireless networkaccess or user identification, but rather integral to the device itselfin identifying this device, for example, in allowing for the addressingof wireless communications thereto by nearby or associated devices.

In one such embodiment, the hotspot 1306 is programmed to listen forprobe requests transmitted by devices actively scanning for availablenetworks. These types of packets are periodically broadcast by Wi-Ficlient devices (part of the IEEE 802.11 standard) in seeking to identifyavailable network connections. Contained in such probe requests is avalue that uniquely identifies each device (its MAC address) so thatreplies can be addressed specifically to that device. In this particularembodiment, the hotspot sensor 1306 forwards identified probe requeststo a centralized controller 1310 (e.g. delivered in its raw form to aremote server) for processing by listener 1312.

In this particular embodiment, the packet listener 1312 listens forincoming packets and extracts the MAC address of the client device 1302that originally issued the probe request, the IP address of the accesspoint (sensor) 1306 that detected the packet, and the timestamp of thepacket, for example. As introduced above, extraction of the MAC addressallows for unique identification of the device 1302 at the hotspot 1306,and extraction of the IP address and time stamp allows, in someembodiments, for the identification of the hotspot location and thus theidentified device's location, and the time to be associated therewith.For instance, the IP address can be cross-referenced with a database ofknown access points to determine which location it corresponds to.Similarly, the extracted device identifier can be cross-referenced withstored device profiles such that repeat visitors can be recognized uponsubsequent visits to the same or related locations, or again atunrelated locations for the purpose of expanding the device profiledatabase across multiple operators (device profile sharing rules betweenentities may be set in place to protect user privacy and the like, aswill be readily appreciated by the person of ordinary skill in the art).Combination of the device ID, location ID, and timestamp thus provide anindication that a particular device 1302 was present at a particularlocation at a particular time.

In one embodiment, the extracted data can be used to recognize and thustrack devices over time at different locations, and can also be used togenerate and maintain an in-memory map of where each recognised deviceis, and optionally how long it has been there. From this point, the datacan be sent, for example at regular intervals, to an M2M service module1314 that aggregates packet capture data, optionally with other forms ofpresence information, to create a high-level picture of which devicesare present at which locations, and for how long. This information canbe stored in a knowledge base (KB) database 1316 from where it can beused for various purposes such as reporting, business analytics, anddiagnostics, to name a few. The M2M module 1314 may also be used to passevents to external subscribers for real-time notification and/orreporting, for example.

In some embodiments, device identification and recognition, deviceprofiling, and as will be described in greater detail below, devicevisit profiling, may be implemented internally by a given entityoperating a local, regional or global hotspot locations (e.g. at asingle location, at any of a group of commonly operated regionallocations, and/or globally across multiple locations), or againimplemented by a third party hotspot operator, which may servicemultiple hotspot operating entities in providing each one withrespective and customized data in respect of devicesidentified/recognized at their service locations and/or across theentire serviceable network of hotspots.

In the context of FIG. 13, third party operations may thus shareresources between commonly operated hotspot locations, or again betweendistinct customers, by centrally processing packet captures and/or otherdetection events (e.g. RTLS), or again by centrally processing eventdata in compiling respective visit profiles, managing device profilesacross multiple customer platforms, and managing respective rulesengines (e.g. see FIG. 15) for different consumers in deliveringcustomized data, as appropriate. In such embodiments, again, privacyregulations may be implemented to limit exchange of data betweenconsumers, for example where different levels of engagement have beenrecorded for a given device from consumer to consumer (e.g. an opt-indevice may authorize access to personal information in respect of aparticular hotspot operator, but may be set to operate anonymously inrespect of another).

Similarly, while third party resources may be used exclusively for theprovision of hotspot network access and device data acquisition andprocessing, leaving downstream application implementation to theconsumer, other embodiments may redirect consumer actions back throughthe third party system for direct interaction with user devices. Eitherway, different privacy protocols may be implemented to reduce directuser device exposure to the consumer, thereby protecting a user'sprivacy and anonymity, particularly where a user's device's interactionshave been limited to unsolicited packet captures, or the like. In suchexamples, a MAC address automatically extracted from anonymous devicetransmissions may still be used to compile activity data, and optionallyprovided for downstream use via a hashing protocol, thereby avoidingdirect disclosure of the anonymous MAC address to the consumer. Theseand other such privacy settings will be readily apparent to the personof ordinary skill in the art and are likely to vary from area to areabased on evolving local privacy regulations and the like.

As introduced above, other techniques may also be used, in conjunctionwith basic device detection and recognition, to supplement devicetracking and further develop the knowledge base. For example, whiledevice identification and recognition may be implemented via packetcapture of probe requests, as noted above, other packet captures and/orlogging/tracking techniques may also or alternatively be used inconjunction therewith to automatically access a greater representationof user activity. For example, multiple data exchanges may be trackedbetween the device and a hotspot access point while negotiating andultimately accessing the hotspot network. Similarly, one or more radiosmay be used at the hotspot location to identify and tracking visitingdevices. For example, multiple radios may be used at a same location topromote greater proximity data acquisition (e.g. multiple RTLS radios)and thus increase accuracy of the downstream analytics relying on suchdata.

FIG. 14 schematically illustrates hotspot engagement levels forcharacterizing a device visit at or near a given hotspot location.Namely, passive visitors 1402 may carry devices that are, at the highestlevel, merely detected as being present within the vicinity of thehotspot. In one example, passive device detection may occur at firstlevel via a probe request packet capture or an RTLS detection, asdiscussed above, thereby directly identifying the device at or near thehotspot.

In a similar fashion, device communications may be intercepted via athird party receiver (e.g. a receiver in the area of the hotspot inquestion but not necessarily associated with the hotspot itself, thatis, potentially operated by un unrelated entity and/or not readilyaccessible by the common knowledge base). For instance, a particulardevice may be out of range for a particular hotspot receiver to detectit, but may still communicate with another unrelated Wi-Fi transceiver,which unrelated transceiver is itself within range of the particularhotspot receiver. This example is shown schematically in FIG. 13,wherein unrelated hotspot 1307, in range of one of the system's hotspots1306, exchanges data with a wireless device 1303 that is not withinrange of this system's hotspot 1306, for example, in processing arequest for network access, exchanging authentication information, ormanaging an active network connection with the device 1303. Accordingly,while transmissions emanating from the device in question 1303 may notbe captured by the particular hotspot receiver 1306 of interest,communications emanating from the unrelated transceiver 1307 andintended for the device in question may themselves be captured by thehotspot receiver 1306 and thus identify the presence of the device 1303within the area of the hotspot 1306. Clearly, such communications wouldagain reflect the presence of a passive visitor, but such informationmay nonetheless be of interest in compiling visitor analytics in respectof the hotspot location of interest 1306. Furthermore, sincecommunications emanating from the unrelated transceiver 1307 willnecessarily include reference to a specific transceiver identifier (i.e.an access point MAC distinct from the access point MAC of the hotspotlocation 1306 of interest), the system may be configured toautomatically distinguish local (direct) from foreign (indirect)visitors, and, possibly, to perform comprehensive analytics as to thenumber of visitors associated with nearby locations as compared to thosepresent at their own location (i.e. competitor intelligence could becompiled). In any event, the device may still be recognized from aprevious visit at the same or another hotspot location populated in thedevice's stored device profile, or identified as a new device andrecorded in the creation of a new device profile.

Again with reference to FIG. 13, in one illustrative embodiment, thesystem 1300 may further or alternatively comprise or be configured tointerface with a set of Wi-Fi radio locations 1309 operatively disposedin different locations to, much as in the context of the hotspots 1306,allow the system 1300 to identify and recognize remote devices 1302 whenin their general vicinity. For example, such radios 1309, while notoperated to provide devices with wireless access to a networkconnection, may nonetheless operate to capture local transmissions sentby these devices and extract therefrom a unique device identifier (e.g.MAC address via packet capture or RTLS) to be cross-referenced with theknowledge base and, where a match is made, allow recognition of thedevice as being present at the given location, and otherwise allow forthe creation of a new device profile. Again, given the passive nature ofthe intercepted wireless transmissions, such device visits would becharacterized as passive visits. Regardless, valuable market data maystill be compiled with respect to the devices identified at eachlocation, as can device visit profiles be created and stored, as will bedescribed in greater detail below. Much like device identification andrecognition at an active hotspot, devices recognized at a given locationthat have opted-in for or authorized (directly or indirectly) the systemto communicate directly therewith upon detection, may be targeted uponsatisfying certain criteria, such as upon qualifying as a repeat orloyal visitor, a new visitor at a particular location, meeting certaintarget demographics, etc.

Active visitors 1404, on the other hand, may be progressivelycharacterized as hotspot associated, whereby the device's radio hasidentified the hotspot access point and is attempting to connect;hotspot active/intercepted, in which the device is actively connected tothe network but not yet authenticated for access to the Internet, forexample (e.g. may yet to enter authentication credentials, temporarypassword, network access key, or the like); and/or hotspotauthenticated, whereby a device has been authenticated for networkaccess at the hotspot. Further engagement may also be provided, as willbe described in greater detail below, by way of a user opting-in forservices, promotions, applications and/or packages, for example, ormerely by accepting terms and conditions laid out in exchange for freeopen access to the hotspot network connection, for example. Such opt-inor service access conditions may include express authorization by theuser for designated system access privileges to the device and/or touser data stored thereon, or include the volunteering of user data byway of user action on the device for system storage and use. As eachlevel of interaction provides an increasing or at least continuingability to extract information from the device and/or to characterizethe device's activity via recognizable network communications, furtherinformation can be gathered in respect of the device's user by trackingnot only device identification and recognition, but also an engagementlevel and visit duration. Conversely, it will be appreciated that fewerand fewer visitors will be identified with increasing levels ofengagement. Based on the acquired data, it may be that a given hotspotoperator may attempt to increase engagement by visitors, for example byway of “network access” or “opt-in” incentives, so to increase itsaccess to device and/or user data and thus enhance device profileanalytics and applications. Irrespective, each engagement level providesthe system access to recognizable device transmissions, which, in oneembodiment, may include an access point MAC address (e.g. forcross-referencing hotspot location) and a device MAC address (e.g. fordevice recognition), and further include for association andauthentication level events, an event start/stop value. Each event mayalso have associated with it a date/time stamp, for example. Where anRTLS module, for example, is also or alternatively used, a signalstrength of the device may also be captured, thereby allowing forfurther characterization of the visit, namely, as a function of userproximity to the hotspot location (e.g. internal or external to theestablishment providing network access), which proximity may also belogged as a component of the device visit.

In one example, and as will be further exemplified below, the system maybe configured to wirelessly transmit an engagement offer to the devicethat requires user action on the device for implementation and thatultimately results in the system gaining enhanced communicative accessto the device. Upon subsequently detecting and recognizing the device,the system may be configured to use this enhanced communicative accessto automatically engage a user of the device (e.g. without user input).For example, in one embodiment, the requested user action results in thetransmission of user contact information to be associated with thedevice profile in the knowledge base (e.g. automatically extracted fromthe device or directly or indirectly input by the user). Upon subsequentdetection and recognition of the device at the hotspot or a relatedhotspot (or again at one or more passive system sensor locations, suchas sensors 1309 of FIG. 13), the contact information can be accessedfrom the knowledge base and used to communicate a message to the device.

Similarly, the requested user action may rather or also result in thedownload of an application (e.g. app) associated with the hotspotlocation, or a designated group of hotspot locations, to be operated onthe device. In doing so, a unique application identifier may be storedin relation to the device's profile and used to communicate directlywith the downloaded application operating on the device when the deviceis subsequently identified and recognized at one of these hotspots (orrelated sensor locations).

In one example, a particular device visit is compiled as a series ofevents over time captured and logged by the system, from initialdetection in one example by way of MAC address packet capture upon thedevice scanning for available network connections, followed by networkassociation, interception and/or authentication upon the user gainingaccess to the hotspot network (which may last anywhere between a fewminutes to a few hours), to termination upon the user breaking theconnection, upon the system logging a final packet capture event, oragain upon the user turning off the device (e.g. a laptop may be shutdown before leaving the location, whereby a finalizing packet capture isnot available to mark the device leaving the location, as may otherwisebe available from a smartphone device or the like that remains activatedas the device leaves the location). The network disconnection event,much like a final packet capture event, may therefore act as a visitclosing point as the last detected action of the device at the hotspot.In this scenario, a comprehensive visit profile can be compiled from acombination of passive and active detection mechanisms to enrich thedata collected as it pertains to a particular visit.

FIGS. 14B to 14D provide examples of visit profiles for a given locationthat may be compiled using the above considerations, which profiles maythen be used to gain market intelligence on the location's clientele, togear marketing and/or promotional efforts, to allocate resources and/orproject product or service demands, and/or to target selected clients orclient groups, for example. An optional visit proximity profile isoverlaid on the visit timeline profile, for example rendered viaproximity data extracted from an RTLS data stream, in furthercharacterizing a device visit. Clearly, a visit proximity profile may beused independently to produce usable results, as will be furtherillustrated by the below-described examples. Further, while packetcapture detection is considered in the below examples for devicedetection, an RTLS data stream may otherwise be used to provide similareffects, the added option of further capturing signal strength data tofurther characterize device proximity.

In the example of FIG. 14B, a uniquely identifiable device is firstdetected by way of packet capture (or RTLS). The device is thenassociated with the hotspot and later authenticated for wireless networkaccess. Packet capture again identifies the device before theauthenticated session is closed. As no further detection events takeplace after network disconnection, the visit is characterized by thetime lapse from first detection to authenticated assess termination.Based on the duration of the visit (e.g. upon the visit durationexceeding a preset threshold), and the level of engagement recorded(e.g. authenticated access generally associated with an engaged patron),the visit is classified as an active walk-in, and thus as a likelyprofitable patron that may be likely to return given his lasting use ofavailable network resources. Note that proximity data may be used inconjunction with the engagement timeline to further characterize thevisit. For instance, in this example, signal strength data is processedto indicate proximity of the device as exceeding a preset proximitythreshold 1450, thereby indicating a high likelihood that the device isin fact located within the hotspot operator's premises or establishment,thus confirming the visit's status as an active walk-in. Shouldproximity data indicate otherwise, the system could question whether thedetected device is in fact making use of hotspot services withoutnecessarily supporting the hotspot operator, and take appropriate actionor log the visit accordingly. In any event, and as noted above, uponcross-referencing the device's unique identifier (e.g. the MAC addressextracted upon initial detection, possibly enriched by recognizableattributes associated therewith in the device profile and associatedwith network access authentication) with a database of known deviceprofiles, the visitor may further be characterized as a returningcustomer (e.g. if previously identified at this location or at one ofseveral associated locations), or as a potentially new customer (e.g. ifnever before detected at this or related locations, but potentiallypreviously identified and logged at an unrelated location). In anyevent, the visit may be recorded in the stored profile, or in a newlycreated device profile in the context of a new visitor heretofore neverdetected by the system, for recognition upon subsequent detection atthis or another location.

In FIG. 14C, on the other hand, a device is briefly detected (e.g. viapacket capture or RTLS), thus defining a visit more likely associatedwith a walk-by, namely an individual that did not necessarily patron thehotspot location. Tracking these visitors may, as will be described ingreater detail below, provide information useful in drawing in suchwalk-by visitors, thus effectively seeking to convert them to walk-ins.In the context of this example, and where RTLS is used, proximity datamay again be used in combination with event timing/visit duration datato further characterize user activity. For example, a short durationvisit may be characterized as a walk-by where no further data isavailable, but may otherwise be characterized as a short walk-in whereproximity data indicates that the device did in fact enter the premisesof the hotspot operator (e.g. where proximity exceeds a preset threshold1452). In the coffee shop example, a patron could come in and out of thecoffee shop within a few minutes, but nonetheless warrantcharacterization of the visit as a walk-in. Accordingly, engagementlevel, visit duration and proximity data may be combined, whenavailable, to refine characterization of a device visit.

In FIG. 14D, a repeat visitor is identified for a same location (ordifferent locations tracked as part of a same group). For instance, afirst visit may include a simple passive walk-in visit (e.g. in thecoffee shop example, a visitor may be stopping in to pick-up a coffee togo without intentionally engaging the hotspot network), wherein thedevice is first detected but never further engaged before a finaldetection takes place a few minutes later. Combining identificationevent data with proximity data, again illustratively shown in thisexample as a y-axis increasing with proximity to the hotspot (i.e.increasing signal strength) the system can better distinguish between atrue passive walk-in event (e.g. where a proximity threshold 1454 ismet) and an event in which the device, while close enough to be detectedby the system, may in fact have been located outside or next door to thepremises in question, or again detected via third-party communicationspicked-up by the hotspot radio, thereby still potentially logging-in avisit of sufficient duration to qualify as a walk-in, but in factrepresenting a “close” walk-by. In any event, later that day, the samedevice may be detected and recognized, this time further engaging thesystem via authenticated network access and direct engagement,characterizing the visit as an engaged repeat walk-in visit. Followingfrom the above coffee shop example, engagement may be introduced via aproduct or promotional offering, whereby a user may elect to “opt-in”for a particular service via a network landing page or the like, thusexchanging further information with the system to enable or activate theopt-in service. For example, the user could select to download a freeiTunes™ song in exchange for filling-in a customer loyalty form,providing their e-mail address for a chance to win a free gift orservice, or again downloading a free location-specific or related appfor implementation on their device, which app then readily accessible bythe hotspot operator for subsequent interaction with the visitor. Inthis last example, a visitor accessing a hotspot location at an airportmay be offered a flight status app or the like to be implemented ontheir device, which app may later be accessible by the hotspot orrelated operator to promote airport shopping or services upon detectingand recognizing the device during a subsequent visit (e.g. send ascanable coupon via the app to promote a certain shop or restaurant).Other examples may include, but are not limited to, the exchange of SMSmessages, device and/or user association with the hotspot operator via asocial network or the like (e.g. Facebook™ “like” status, twitteraccount following, etc.), etc.

Upon such engagement, not only can the system track engagement of thisparticular device, further information relating to the user(s) of thedevice, or the device itself, may be extracted, either directly as inputby the user, or indirectly upon the user accepting certain terms andconditions required in receiving the opt-in service (or again requiredupon requesting free network access privileges). As will be described ingreater detail below, acquisition of such further information can bestored and associated with the device profile, and used downstream toenhance the user's experience and promote further patronage, forexample. For instance, as noted above, a repeat ‘opted-in’ visitor maybe automatically identified and recognized upon detection, andautomatically prompted by the system. Following the above-example, anopted-in visitor having provided his e-mail address may receive anautomated greetings from the system, which may include a promotionalincentive for the visitor to further enhance patronage of the hotspot orrelated location. Other examples will be provided below in respect ofthe embodiment described with reference to FIG. 18.

Accordingly, the system 1300, and its equivalents, may be configured tocompile data in respect of each device visit to a particular hotspot,whereby visit data gathered and compiled in respect of each detecteddevice, and optionally at different locations, may be combined toprovide market intelligence as to the type of users frequenting aparticular location and/or type of establishment, the amount of timespent at each location, the level of engagement with the system while ateach location, and so on. Proximity data may also be used tocharacterize spatial movements of recognized device and furtherdistinguish hotspot patrons from non-patron visitors. Further, throughdevice recognition and visit profiling, evolution as to a particulardevice's engagement with a given hotspot location, or group of hotspots,may be tracked/monitored to evaluate the general effectiveness ofmeasures implemented for drawing-in further patronage, for example. Datamay be used specifically to evaluate engagement, and indirectlypatronage by the user(s) of a particular device, or used in combinationwith data compiled for a select group of recognizable devices, orglobally for all recognizable devices identified in respect of aparticular hotspot location of group, thus drawing on averagedperformance measures to systematically increasing patronage, engagementand/or exposure. Clearly, different visit profiles and characterizationsmay be considered within the present context without departing from thegeneral scope and nature of the present disclosure, as can differentanalytics, reports, applications and features applied as a function ofsuch profiles, as will be further described below.

With reference to FIG. 15, and in accordance with one embodiment, adetailed diagram of the various processes implemented in not onlyidentifying and optionally recognizing a device at a hotspot, but alsoin characterizing a device visit and, as appropriate, outputting arelated notification or report to an interested party (e.g. hotspotoperator) will now be described. In this example, a device 1502 is againfirst identified at a hotspot or similar access point 1506 via packetcapture (PCAP), for example via a PCAP listener 1512 as introducedabove. It will be appreciated that while this embodiment considers theuse of PCAP for device recognition, other means such as provided via anRTLS data stream may also or alternatively be used to provide similareffect, with the potential added benefit of leveraging signal strengthdata available via RTLS and its equivalents. The PCAP event may providea first detection instance in a particular visit, but may also providesubsequent detection instances, for example at regular intervals as perthe normal operation of the device, which may periodically probe itsenvironment for available network connections. Other event sources, suchas a syslog in the context of authenticated network access, interactionwith an opt-in service or application implemented on the remote device,and the like, can also be used to enrich visit data, each such eventgenerally handled by the M2M module 1514 by respective eventlisteners/handlers 1522. A visit creation and aggregation module 1524 isoperatively associated with the event handlers 1522 to aggregate andstore in knowledge base 1526 a visit profile for each uniquelyidentified device. In this particular embodiment, each visit is queuedby a visit queue 1528 and processed by a data engine 1530 configured toreceive, qualify and act upon compiled visit profiles, e.g. to isolate,filter and/or consolidate visits satisfying designated rules for furtherprocessing, reporting and/or action. For example, a particular visitprofile may be pulled from the queue 1528 and processed through a rulesengine 1532. Upon the visit profile matching a particular rule set atstep 1534, the visit profile can be identified to an action engine 1536with a particular action to be performed identified by the matching ruleset, for output to the downstream consumer 1538 at step 1540. Anexemplary action may include an HTTP Push Notification to the consumer,or other such reporting functions as will be illustrated in greaterdetail below.

Different illustrative rules may include, but are not limited to, rulesfor characterizing a selected visit as a function of preset conditions,such as duration and/or proximity (e.g. walk-in vs. walk-by), level ofengagement (e.g. passive vs. active), type of engagement (e.g. detectedvs. authenticated vs. opt-in device), opt-in status, etc.; rules foridentifying visitors (e.g. opted-in visitors, return visitors, newvisitors, long duration visitors) to whom targeted content may be pushedand/or with whom direct interaction should be promoted; reporting rulesbased on one or more visit qualifiers set as being of particularinterest to the downstream consumer; etc. As will be appreciated by theskilled artisan, and as introduced above, rules may be set as a functionof preset thresholds (e.g. proximity threshold or range, durationthreshold or range, visit frequency and/or range, etc.), wherebycross-referencing of real-time and/or device/visit profile data withsuch thresholds may allow for adequate characterization of the device,its user, and their visit at the hotspot or similar location.

With reference to FIG. 16, and in accordance with one embodiment, anillustrative data management interface 1600 will now be described. Inthis example, a consolidated management interface can be provided toconsolidate device identification and recognition data, report andanalyse device activity and visit patterns, and so on. In thisparticular example, data is isolated for all operators 1602 andlocations 1604 of a selected Brand 1606, such as Starbucks™, forexample, and that, for a selected date range 1608. Accordingly,aggregated data will be consolidated to present average activity datafor all participating locations of this particular Brand, in thisparticular example, formatted to represent a visit dashboard (e.g. aselected subset of “at-a-glance” visit analytics for the selectedperiod).

In the selected view, a chart 1610 is provided tracking visits per hourduring the course of a day, and comparing average visits over theselected data range (30 day trend) to current data (real-time tracking),thus visually identifying a current above-average number of visits perhour across all locations. A pie chart 1612 is also provided breakingdown percentage total visits by day. A bar graph 1614 shows a percentagedistribution of visits as a function of visit duration, showing asignificant fraction of visits lasting approximately 15 minutes. Abreakdown of visits per most-visited locations 1616 is also provided,distinguishing Total Visits 1618 from Unique Visitors 1620 (i.e.collapsing repeat visitors). Other features and applications are alsomade available in the illustrated interface, including options forconsolidating data on: Visit duration analytics; Unique location visitanalytics; New visitor analytics; Day by day hourly visit analytics;Daily visits analytics; and Customer engagement analytics, to name afew.

With reference to FIGS. 17A and 17B, regional and location-specificdashboards are respectively represented. In the regional dashboard ofFIG. 17A, data is compiled and displayed in respect of 5 designatedlocations in a given area. Selected data windows include the totalnumber of visits for the day further subdivided as walk-bys (visitslasting less than 5 minutes in one example, thus suggestive that theuser of the device may not have actually entered the premises, or againoptionally further characterized by a visit during which deviceidentification events were combined with proximity data to confirm thatthe device never entered the premises.), and walk-ins (visits lastingmore than 5 minutes). Another selected window includes the total numberof unique visits for the day (i.e. taking into account those makingmultiple visits, which may include those walking by repeatedly and thusbeing detected and recognized as such), again subdivided in to walk-insand walk-bys. Another selected window classify recent walk-ins (e.g.visits detected to last more than 5 minutes) as loyal, casual or newvisitors (e.g. based on preset loyalty rules). For example, devicesrecognized to attend one of the regional locations at least twice a weekmay be categorized as a loyal visitor, as compared to one recognised toattend only twice a month and thus characterized as casual. Similarly,recent walk-bys may also be characterized as such. Respective windowsare also provided in this example to show a number of walk-ins withinthe last hour and an comparative indicia identifying a percent change inthis value as compared to the previous hour; a number of walk-bys withinthe last hour and an comparative indicia identifying a percent change inthis value as compared to the previous hour; and a pie chart trackingwalk-in visit durations for the day in progress.

In the location-specific dashboard of FIG. 17B, data is compiled anddisplayed in respect of a singular location. Selected data windows inthis example are similar to those depicted in the embodiment of FIG.17A, with data necessarily representative of visitor traffic andactivity within a single location.

Using substantially real-time data, as illustrated in FIGS. 17A and 17B,and at a higher level in FIG. 16, a hotspot operator may proceed to makeeducated decisions as to how to market or promote their services, namelyin seeking to attract further clientele (e.g. investigate options fordrawing in walk-bys, and particularly repeat walk-bys that may, forinstance, be predicted to frequent a competing establishment in thearea), and/or to better service existing clientele and encourage furtherengagement. Using real-time and/or regular data updates a local orregional operator may track immediate results to different marketing orpromotional campaigns aimed at improving patronage. For example, a localcoffee house hotspot operator may observe that walk-ins dropsignificantly during certain periods of the day or again on certaindays, and investigate potential reasons therefore, which may lead tocreative solutions to draw in greater patronage at those times or onthose days. Similarly, peak walk-by periods may suggest the use of amore aggressive sidewalk promotion strategy around those periods to drawthese visitors in. Other considerations may rely on acquired deviceprofile data to plan for services and demand on given days, or duringcertain periods of the day. For example, while sales receipts may allowtracking of variable demand patterns, visit duration data may allow forgreater insight as to physical space allowances, visitor comfort (i.e.would increasing visitor comfort or improving visitor environment helpprolong visit durations and boost sales, or hinder flow through of newwalk-ins.).

Similarly, given the potential real-time nature of the acquired data,immediate reporting or push notifications may be dispatched to thelocation in question to incite immediate action. For example, wherewalk-in rates show a significant drop over the course of the last hour,a location manager may immediately evaluate conditions that may have ledto such decrease (e.g. overcrowded space or limited seating, shortage oncertain menu items for a coffee shop or restaurant, loud or unpopularbackground music, disturbingly loud group of patrons, etc.). Access tosuch immediate observations on patronage and engagement may thus lead tofaster identification and remediation of perceived issues, or again tonoting particular characteristics or settings seemingly conducive to anincrease in patronage (e.g. live music, effective sidewalk advertising,personal greeter at the door, etc.).

Similarly, the immediate identification and recognition of repeatpatrons may trigger a more receptive or dedicated service, as canrecognition of “opt-in” devices at a given location be used to pushinstant notifications to those devices or again to serviceproviders/sales representatives at the location to encourage provisionof enhanced services, communicate a “usual” order to the cashier beforean order is actually made, or simply allow for a personal greeting to a“regular” who may otherwise expect to be personally recognized bylocation.

Accordingly, the compilation of such data may allow for direct orindirect reporting of business intelligence metrics and/or analyticswhich may be utilised to adjust or refine business practices and/orofferings and to observe immediate, short and/or long term effects ofsuch refinements on the business's clientele and performance. As notedabove, reports may be rendered “at-a-glance” in the form ofcomprehensive and/or customizable dashboards, as instant notifications,or alternatively rendered as detailed business intelligence reports fordetailed analysis.

Reporting can also take different forms depending on the intendedanalysis to be performed and intended outcome and application of suchanalyses. For example, data may be compiled to provide locationsegmentation reporting, such as to determine and illustrate a mix ofdevices recognized at a given location or group of locations (e.g.number of loyal/regular/occasional/new customers at a given time orduring a given period). Data may also or alternatively be compiled toprovide device segmentation reporting, such as to qualify the visitpatterns of a particular device (e.g. Loyal/Regular/Occasional/etc.).Where a device has been opted-in to a particular service offering inexchange for the rights to disseminate, exchange and/or use the device'suser's personal data (e.g. demographics) and/or communication streams(e.g. e-mail, SMS, social network, etc.), reports may also, oralternatively include specifics extracted from the device and/or userindicative of the user's gender, age, past purchase history, visitprofiles, social status, etc. On the latter, further details andexamples as to the various manners by which social data may beextracted, combined and bound with a user's device profile can be foundin Applicant's co-pending United States Patent Application No.2012/0192258, the contents of which are hereby incorporated herein byreference in their entirety. It will be appreciated that other types ofreports may be considered herein, as can different permutations andcombinations thereof, without departing from the general scope andnature of the present disclosure. The above also provides a fewillustrative examples as to different applications to deviceidentification, recognition, and tracking. Other such applications areclearly intended to fall within the general scope and nature of thepresent disclosure, as will be further detailed below.

With reference now to FIG. 18, and in accordance with some embodiments,illustrative downstream applications for a device detection andrecognition system will now be described. In this example, wirelessdevices 1802 at a given hotspot or similar location 1806 may be detectedand respective device profiles 1808 created and/or populated inknowledge base 1810 to track and report on device activity at thislocation. A respective location state 1812 is generally associated witheach device profile instance, along with a timestamp or the like, asnoted above, to ultimately characterize device presence/activity,location and timelines (e.g. visits) for further processing. In thisembodiment, knowledge base data is made accessible to a consumer througha retailer API 1820, or the like, so to update store (location) states1822 and provide visitor presence notifications 1824, for example. Forinstance, store state updates 1822 may include, but are not limited to,the push or pull of global, regional and/or local visitor dashboardupdates, or the like, so to allow for the substantially real-timeprocessing of visitor activity data in extracting immediate or nearimmediate market intelligence. In some embodiments, immediate action maybe initiated as a function of store updates, such as the application ofinstantaneous promotions, service upgrades, or again, in increasingnetwork access coverage and/or capacity where visitor updates areindicative of an increased demand for network access, for example. Longterm projections and analytics may also or alternatively be compiledbased on updated data compiled over time.

In this example, the retailer API 1820 communicates with one or moreretailer applications 1826, which may also access retailer CRM data andcontent 1828 to supplement interactions with visitors at the hotspotlocation(s). For example, retailer applications 1826 may be configuredto provide targeted Wi-Fi hotspot content 1830 to visitors, namelyvisitors actively engaged via network authentication or opt-in visitorsreadily accessible, for example, by way of contact data or informationvolunteered by the visitor during the opt-in process (e.g. socialnetwork interface/account-related content, web content or pop-upadvertising, foreground inset content, background content, etc.).Additionally, or alternatively, targeted content may be pushed viaretailer app integration 1832 on the visiting device, for example oncedownloaded upon opting-in for related services. Other examples of pushedor targeted content may include the sending of an e-mail or SMS message,for example, where such contact information has been volunteered orextracted and used under approval by the user of the device, again,possibly in the context of network engagement at a given hotspot.

For example, a device may opt-in to receive promotional information forman airline and its affiliates upon using the airline's network accessservices in their first class waiting lounge. Following from thisexample, the airline may be affiliated with a hotel chain such that,upon the user's device being detected at the airport lounge prior toleaving for a flight, the device owner's flight information may beretrieved by cross-referencing the user's e-mail as provided during theopt-in process for receiving promotional information, with an e-mailcontact field associated with the user's flight ticket. Accordingly, theuser's destination for that day may also be identified, allowing fortargeted content associated with this destination (e.g. hotel chainlocation at the user's destination) to be pushed to the user. In asimilar manner, upon the user's device being detected and recognized inthe lobby at a given hotel chain location associated with the opt-inairline, a targeted message could be sent to the device welcoming theuser and offering one or more promotional incentives, such as a roomupgrade, complimentary breakfast, or the like.

As will be appreciated by the skilled artisan, from implementation ofdevice location and recognition at different hotspot or similarlocations within a given network as described above, and further byoptionally tracking device engagement levels, visit profiles, and opt-instatuses and the like, myriad applications may be implemented toleverage the information gathered, tracked and compiled in real-timeand/or over time to enhance network user experience, customer targeting,promotional efforts, operational projections, cross-partnership oraffiliation advertising, to name a few.

While the present disclosure describes various exemplary embodiments,the disclosure is not so limited. To the contrary, the disclosure isintended to cover various modifications and equivalent arrangementsincluded within the general spirit and scope of the present disclosure.

1-49. (canceled)
 50. A method for recognizing a wireless device acrossmultiple hotspot locations, the method comprising: detecting, using oneor more hardware processors, at one of the multiple hotspot locations awireless transmission sent by the wireless device; extracting a uniquedevice identifier of the detected device from said wirelesstransmission, said unique device identifier automatically embeddedwithin said wireless transmission by the detected device without userinput; cross-referencing said extracted device identifier with a networkaccessible database of stored device profiles, each of said deviceprofiles having a respective stored device identifier associatedtherewith; and recognizing the detected device upon matching saidextracted device identifier with one said stored device identifier;otherwise automatically creating a new device profile in said databaseas a function of said extracted device identifier such that the deviceis recognized upon subsequent detection at any of said multiple hotspotlocations.
 51. The method of claim 50, further comprising: tracking thedevice via said device profile to recognize returning devices at a samehotspot.
 52. The method of claim 50, further comprising: providing thedevice access to an available network connection at said one hotspot;and accessing additional data distinct from said unique deviceidentifier from said device upon said device accessing said availablenetwork; associating said additional data with said device profile;accessing said additional data upon subsequently recognizing said deviceat any of said multiple hotspots; and tailoring user experience via thedevice as a function of said additional data.
 53. The method of claim50, further comprising: identifying a location of said hotspot;associating said location with said device profile; and tracking atleast one of usage location patterns of the device and usage by locationfor multiple devices via said device profiles.
 54. The method of claim50, said device identifier comprising a value indicative of an inherentcharacteristic of the device.
 55. The method of claim 54, said inherentcharacteristic comprising a MAC address of the device.
 56. The method ofclaim 50, wherein said wireless transmission comprises a scanningtransmission scanning for an available network connection at said onehotspot.
 57. The method of claim 56, wherein said scanning transmissioncomprises a probe request automatically transmitted by the device inscanning for the available network connection, and wherein saidextracting comprises extracting a MAC address of the device from saidprobe request.
 58. The method of claim 50, further comprising: compilingfor a given hotspot location or for a designated group of said hotspotlocations, and for a designated reporting time period, a number ofrecognized devices uniquely identified during said time period; andoutputting said at least one number or an indicia representativethereof.
 59. The method of claim 50, further comprising: compiling for agiven hotspot location or for a designated group of said hotspotlocations, and for a designated reporting time period, a number or apercentage of said recognized devices identified over said time periodsatisfying a preset loyalty threshold defined by a number of recognizeddevice visits at said given hotspot location or at any one of saiddesignated group of said hotspot locations over a preset time period;and outputting said number, said percentage or an indicia representativethereof.
 60. The method of claim 50, further comprising wirelesslytransmitting an engagement offer to the device, said engagement offerrequiring user action on the device for implementation, said actionresulting in enhanced communicative access to the device; and uponsubsequently detecting the device, using said enhanced communicativeaccess to automatically engage a user of the device without user input.61. The method of claim 60, said action resulting in transmission ofuser contact information, the method further comprising: receiving andstoring said transmitted user information in association with saiddevice profile; and upon subsequently detecting the device,automatically communicating a message to the device via said contactinformation.
 62. The method of claim 50, further comprising: detectingat said one of the multiple hotspot locations a sent wirelesstransmission sent to an other wireless device by a distinct hotspotlocation within range of said one of the multiple hotspot locations;extracting an other unique device identifier of the detected otherdevice from said sent wireless transmission, said other unique deviceidentifier automatically embedded within said sent wireless transmissionwithout user input; cross-referencing said extracted other deviceidentifier with said network accessible database of stored deviceprofiles; and recognizing said other detected device upon matching saidextracted other device identifier with one said stored deviceidentifier; otherwise automatically creating a new device profile insaid database as a function of said extracted other device identifier.63. The method of claim 50, further comprising: detecting at a passiveWi-Fi receiver location a wireless transmission sent by the device;extracting said unique device identifier to recognize the device; andlogging a device visit at said receiver location in said device profile.64. A system for tracking wireless devices across multiple hotspotlocations, the system comprising: a network accessible database havingstored therein a plurality of device profiles each identifying arespective wireless device by a stored unique device identifier, eachsaid stored unique device identifier indicative of an inherentcharacteristic of said respective device; and a network access module,comprising one or more hardware processor, at each of said locations andconfigured to detect at a given location a wireless transmission sentfrom a given device and having embedded therein a transmitted uniquedevice identifier inherent to said given device; said network accessmodule interfacing with said network accessible database tocross-reference said transmitted unique device identifier with saidplurality of device profiles to identify a matching profile and therebyrecognize said given device, and otherwise automatically create a newdevice profile based on said transmitted unique device identifier so torecognize said given device upon subsequent detection at any of saidmultiple hotspot locations.
 65. The system of claim 64, wherein saidnetwork access module comprises a gateway configured to intercept saidwireless transmission and redirect same to a network accessibleprocessor programmed to extract said transmitted identifier andcross-reference same with said device profiles.
 66. The system of claim64, wherein said inherent characteristic comprises a MAC address. 67.The system of claim 64, wherein said wireless transmission comprises aprobe request automatically transmitted by said given device in scanningfor an available network connection and having embedded therein saidinherent characteristic, said inherent characteristic being a MACaddress of said given device.
 68. The system of claim 64, furthercomprising a packet listener interfacing with said network access moduleand said database to extract said transmitted identifier forcross-referencing with said device profiles.
 69. A method forrecognizing a wireless device across multiple Wi-Fi locations, themethod comprising: detecting at one of the multiple Wi-Fi locations awireless transmission sent by the wireless device; extracting a uniquedevice identifier of the detected device from said wirelesstransmission, said unique device identifier automatically embeddedwithin said wireless transmission by the detected device without userinput; cross-referencing said extracted device identifier with a networkaccessible database of stored device profiles, each of said deviceprofiles having a respective stored device identifier associatedtherewith; recognizing the detected device upon matching said extracteddevice identifier with one said stored device identifier; associatingwith said device profile of said recognized device said one of themultiple Wi-Fi locations; and centrally compiling from said storeddevice profiles, visit data for each of said multiple Wi-Fi locations.